Mike Rowell, OAGi Chief Architect, will be presenting the new
implementation of Code Lists and Enumerations for OAGIS 9.0.

If extra time is available, we will review the recently published
list of candidate ACCs from TBG17.

garret

This is the response from ATG2 regarding the NDR decisions we discussed at our
last conference call.

JOSTEIN FRØMYR wrote:

> Hi Garret,
>
> As you will se from the minutes we discussed your coments in our conference
> call on October 22. For your easy reference conclutions are quoted belowe.
>
> Quote
> The group discussed comments from Garret Minakawa concerning decision made
> during the conference call on October 18.
> a)      Use of xsd:built-in types
> Participants recognised the concerns raised by Garret and would like to
> further discuss this issue with all key members of ATG2 present.
> Atrion: Mark will solicit time for a separate conference call.
> It was also recognised that the qualifiers to be applied in a QDTs should be
> providing a "semantic value" and not a physical representation. An
> alternative solution is to develop more UDTs (and possibly also
> Representation Terms in the CCTS). This would require change request to be
> raised against the CCTS as well as the Core Component Library as issued by
> TBG17.
> b)      Use of capital letters for abbreviations and acronyms
> The meeting reconfirmed its decision to only allow capital letters for
> acronyms.
> The meeting reverted its decision and would like to accept mixed camel case
> for abbreviations provided that the abbreviation does not represent a proper
> word in the Oxford Dictionary. It should also be noted that ATG2 will only
> allow abbreviation and acronym that are part of the controlled vocabulary to
> be maintained by TBG17.
> Atrion: Mark to send message to TBG17 regarding the controlled vocabulary.
> When reviewing the Oxford dictionary it was noted that id is a proper word
> and that the abbreviation for identification or identity is ID.
> Unquote.
>
> Jostein
>
> > -----Original Message-----
> > From: Garret Minakawa [mailto:Garret.Minakawa@...]
> > Sent: 20. oktober 2004 19:55
> > To: jostein.fromyr@...; Mark Crawford
> > Cc: Garret Minakawa
> > Subject: ATG2 Rulings from October 18 Meeting Minutes
> >
> >
> > Jostein/Mark,
> >
> > I'd like to ask for additional information on two of the
> > decisions from you last meeting.
> >
> >           Agree that R143 breaks the inheritance applicable
> >           using xsd:derivation. Using xsd:derivation is one of
> >           the fundamental principles for construction QDTs. Rule
> >           143 should be deleted.
> >  3771R142
> >           We do not support creating QDTs that are not based on
> >           UDT through the use of xsd:derivation. If there is a
> >           business need as suggested in the comment anew UDT
> >           will have to be created
> >
> > I thought another one of the general principles was the utilize
> > xsd built-in types as much as possible.
> >
> > If OAGi implements this rule, we will need to rework several of
> > our existing QDTs.  For example:
> >
> >  Integer_ Numeric. Type  xsd:integer
> >  Float_ Numeric. Type    xsd:float
> >  Positive_ Integer_
> >  Numeric. Type           xsd:positiveInteger
> >  String_ Text. Type      xsd:string
> >  Normalized_ String_
> >  Text. Type              xsd:normalizedString
> >  Token_ Text. Type       xsd:token
> >  URI. Type               xsd:anyURI
> >  Language_ Code. Type    xsd:language
> >  Year_ Date. Type        xsd:gYear
> >  Year_ Month_ Date. Type xsd:gYearMonth
> >  Duration_ Date Time.
> >  Type                    xsd:duration
> >
> > Do you really want to prevent implementers from using these xsd
> > built-in types?  I would think that a lot of people might have
> > problems with this.
> >
> >       No, ATG2 has previously agreed to use all capital letters
> >  4127 for abbreviations and acronyms being part of the
> >       controlled vocabulary. Also se response to line 1705.
> >
> > I've now raised this issue with both UBL and ATG2 and been struck
> > down both times.  However, since the ATG2 ruling applies to all
> > abbreviations, I really must question the reasoning behind this
> > decision.  As far as I know, no standards body or best practice
> > uses all upper case for abbreviations.  It doesn't seem to look
> > right visually (in most cases) and may cause the reader to think
> > it is an acronym instead of an abbreviation.  Please clarify.
> >
> > Thanks,
> >
> > garret
> >
> >
> >
> >
> >
> >
> >

FYI

Stig Korsgaard wrote:

> Dear all,
>
> I know some of you have been waiting for this, and finally we are ready -
again thanks to our editorial technical team.
>
> Enclosed you will find the next set of 38 draft ACC´s center for our
attention and to be worked upon in Palm Beach at our December meeting.
>  <<TBG17 Draft38 26 October.xls>>
> In addition there is also another spreadsheet with the third set of
candidates, that relates to the 38.
>  <<TBG17 Candidates 26 October.xls>>
> It is planned that we will have one or two teleconferences before the meeting
in other to prepare - detailed info to be given later.
>
> The good news is that we will be a good number of participants in December and
we will easily achieve quorum for making decisions.
>
> Best Regards
>
> Stig Korsgaard
> M.Sc.E Standardisation Manager
> Tel:    +45 3370 1083
> Cell:   +45 2725 9083
> Mail:   stk@...
>
> Danish Bankers Association
> Amaliegade 7
> DK-1256 Copenhagen K
> Tel:    3370 1000
> Fax:    3393 0260
> mail@...
> www.finansraadet.dk
>
>   -----------------------------------------------------------------
>                                       Name: TBG17 Draft38 26 October.xls
>    TBG17 Draft38 26 October.xls       Type: Microsoft Excel Worksheet
(application/vnd.ms-excel)
>                                   Encoding: base64
>                                Description: TBG17 Draft38 26 October.xls
>
>                                          Name: TBG17 Candidates 26 October.xls
>    TBG17 Candidates 26 October.xls       Type: Microsoft Excel Worksheet
(application/vnd.ms-excel)
>                                      Encoding: base64
>                                   Description: TBG17 Candidates 26 October.xls
>
>   -----------------------------------------------------------------
>
> ---
> You are currently subscribed to un-cefact-tbg17-voting as:
garret.minakawa@....
> To unsubscribe send a blank email to
leave-un-cefact-tbg17-voting-67427U@...

If you are interested, please send me an email.  Links to the
recording are provided in the "Links" section of the WG web site
but you need approval to view/download the files.

garret

General/Administrative:

Prior to officially starting the meeting, WG received a verbal update from Satish on the eBSC (e-Business Standards Convergence) Forum F2F Meeting on October 20 at LMI.

• Attendance was small with approximately 6 attendees
• Organizations represented included
• UN/CEFACT
• ANSI ASC X12
• UBL
• CIDX/PIDX
• OAGi
• ANSI ASC X12 and CIDX/PIDX reported they are currently not doing an implementation of ebXML Core Components
• OAGi provided a preview of OAGIS 9 and OAGi's implementation of Core Components

First official meeting item was a discussion of the email sent by Stig Korsgaard, Chair of TBG17 and Core Components WG member (21-Oct-2004).

• Given the rule clarification, it is possible for OAGi to submit ACCs/ABIEs for the December TBG17 F2F but not practical
• With only 2 weeks until the submission deadline, it is too late to start development of a new submission.
• It is also difficult because we still do not know what ACCs/ABIEs are planned for review at the TBG17 F2F.

Implementers cannot use an xsd built-in data type for QDTs based on a UDT defined as an xsd:complexType.

• If implemented, these QDTs cannot be used for xsd:attributes (xsd:attributes must be xsd:simpleTypes)
• If implemented, it may be necessary to re-create format validation already built into the xsd built-in type (e.g. the QDT Token_ Text. Type will need to include a xsd:pattern to check for white space and perform other validation that is done automatically by using xsd:token)
• An email was sent yesterday by the Chair to ATG2 asking for additional clarification/explanation of these decisions.
• Action item to create an example of how built-in validation logic will need to be re-created if xsd built-in data types are not used.
• Chair to create example, post to WG list for review and comment, then forward example to ATG2
• WG feels that this ATG2 decision could be implemented if absolutely necessary but does not believe this is the best approach.

• Issue originated from an OAGi comment about the appropriate abbreviation for "Identifier".  OAGi uses "Id" (UCC Convention), UBL and ATG2 use "ID".
• WG was polled to see if anyone was aware of another organization or standard that uses all caps for abbreviations but none were mentioned.
• OAGIS 9 does not use very many abbreviations but when used, they appear in many places.
• WG feels that this ATG2 decision could be implemented if absolutely necessary but does not believe this is the best approach.

Analyze gaps between TBG17 low level ACCs and OAGIS 9:

Started with Period. Details ACC

• TBG17 Object Class is "Period", OAGIS 9 Object Class is "Time Period"
• Group agreed that the use of Period is always within the context of time and duration, not punctuation or other definitions of "Period".
• In order to resolve this gap, three approaches were discussed:
• Change OAGIS 9 ACC from "Time Period" to "Period"
• Submit request to TBG17 to change Object Class from "Period" to "Time Period"
• Create an ABIE "Time_ Period. Details" based on the TBG17 ACC "Period. Details"
• WG decided to create a new ABIE
• "Period. Duration. Measure" BCC in TBG17.  "Period. Duration. Date Time" BCC in OAGIS 9.
• Chair noted that "Duration" was both an xsd built-in type and part of the ISO 8601 standard so it would be more appropriate to use a QDT "Duration_ Date Time. Type" based on the Date Time CCT rather than the Measure CCT.
• Action item to submit change request to TBG17 asking them to change "Period. Duration" to a data type based on "Date Time. Type" and using the ISO 8601 format instead of being based on "Measure. Type".
• WG could not think of a good use case for "Period. Indication. Indicator" and decided not to implement in the ABIE
• WG could not think of a specific use case for "Period. Description. Text" but concluded that it might be useful and would not hurt to include.  "Period. Description. Text" added to the OAGIS 9 ABIE.
• WG preferred the TBG17 Property Term "Start. Date Time" and "End. Date Time" over the OAGIS 9 term "From. Date Time" and "To. Date Time".  TBG17 Property Terms used for OAGIS 9 ABIE.
• WG reviewed the email from Freddy Devos (14-Oct-2004) on the TBG17 mail list regarding "Period. Complete. Date Time".  After some discussion, WG concluded that this concept should not be part of "Period. Details", but some other ACC.

Thanks for the clarification.  I did not understand the distinction between the two deadlines.

One additional question.  In order to help submitters prioritize their work, will TBG17 be able to publish a list of ACCs/ABIEs that are planned for review at their next F2F?  For organizations such as OAGi who have 100s or 1,000s of potential ACCs/ABIEs, we would want to first focus on the ACCs/ABIEs TBG17 is reviewing rather than a set of ACCs/ABIEs that might not be reviewed by TBG17 for another year.

Regards,

garret
 

Stig Korsgaard wrote:

Garret,Let me clarify a mistake here. The deadline that TBG17 works from, that states a 4 week in advance cut-off is not for comments but for submissions. You can therefore still very well comment and work with the next batch after this deadline is passed. You cannot though submit new things for harmonisation. Best Regards

Stig Korsgaard
M.Sc.E Standardisation Manager
Tel:    +45 3370 1083
Cell:   +45 2725 9083
Mail:   stk@...

Danish Bankers Association
Amaliegade 7
DK-1256 Copenhagen K
Tel:    3370 1000
Fax:    3393 0260
mail@...
www.finansraadet.dk

-----Original Message-----
From: Garret Minakawa [mailto:garret.minakawa@...]
Sent: 20. oktober 2004 19:31
To: OAGI-CoreComponents
Subject: [OAGI-CoreComponents] AGENDA: October 21 Core Components WG Conference Call

It appears that TBG17 will not be publishing a list of proposed Core Components to be reviewed at their West Palm Beach F2F (at least not before the four week deadline to submit comments prior to the F2F).  Therefore, I suggest that we defer the work item related to reviewing the next set of TBG17 CCs.  Once the information is available, we will reinstate this work item as our highest priority (assuming no other changes).

Our second highest priority work item was to identify gaps between the approved TBG17 ACCs and OAGIS 9.  I started to do this with some of the larger, more complex ACCs (e.g. Address, Contact) and quickly discovered that unless you start with the lowest level (e.g. most granular) ACCs, it is extremely difficult to deal with the larger ACCs that use the lower level ACCs as building blocks.

My recommendation is to start with lower level ACCs such as Period. Details, Calculation. Details, Dimension. Details, Geographical Coordinate. Details, Range. Details, and Preference. Details then work our way up to larger ACCs with more complex relationships/associations.

We also have some recent decisions by ATG2 that we need to discuss.  Following is an excerpt from their October 18 meeting minutes:
 

3771	R142	Agree that R143 breaks the inheritance applicable using xsd:derivation. Using xsd:derivation is one of the fundamental principles for construction QDTs. Rule 143 should be deleted.  We do not support creating QDTs that are not based on UDT through the use of xsd:derivation. If there is a business need as suggested in the comment anew UDT will have to be created
4127		No, ATG2 has previously agreed to use all capital letters for abbreviations and acronyms being part of the controlled vocabulary. Also se response to line 1705.

The first decision (Line 3771) refers to the use of xsd:derivation when creating a QDT (Qualified Data Type) from a UDT (Unqualified Data Type).  The OAGi comment was that xsd:derivation was not always possible if the QDT was based on an xsd built-in data type and the UDT was an xsd:complexType.  The ATG2 decision states that xsd:derivation must always be used when creating a QDT from a UDT.

This ruling impacts several of the QDTs already used in OAGIS 9.
 

Integer_ Numeric. Type	xsd:integer
Float_ Numeric. Type	xsd:float
Positive_ Integer_ Numeric. Type	xsd:positiveInteger
String_ Text. Type	xsd:string
Normalized_ String_ Text. Type	xsd:normalizedString
Token_ Text. Type	xsd:token
URI. Type	xsd:anyURI
Language_ Code. Type	xsd:language
Year_ Date. Type	xsd:gYear
Year_ Month_ Date. Type	xsd:gYearMonth
Duration_ Date Time. Type	xsd:duration

The second decision (Line 4127) refers to the use of "ID" vs. "Id" for abbreviations.  We had already agreed that UCC (Upper Camel Case) seemed to be more appropriate and consistent for the representation of abbreviations but it appears that ATG2 does not agree.

This decision will have a significant impact on OAGIS 9 if implemented.  Although OAGi strives to minimize the use of abbreviations, there are still several instances where abbreviations are used.  A partial list includes:
 

Doc (or DOC)	Document
Max (or MAX)	Maximum
Min (or MIN)	Minimum
Sync (or SYNC)	Synchronize

 I think this should be more than enough material for our conference call.

AGENDA:

1.  Roll Call
2.  Review and discuss recent ATG2 NDR decisions
3.  Analyze gaps between TBG17 low level ACCs and OAGIS 9
 
 
 
 

Best Regards

Stig Korsgaard
M.Sc.E Standardisation Manager
Tel:    +45 3370 1083
Cell:   +45 2725 9083
Mail:   stk@...

Danish Bankers Association
Amaliegade 7
DK-1256 Copenhagen K
Tel:    3370 1000
Fax:    3393 0260
mail@...
www.finansraadet.dk

-----Original Message-----
From: Garret Minakawa [mailto:garret.minakawa@...]
Sent: 20. oktober 2004 19:31
To: OAGI-CoreComponents
Subject: [OAGI-CoreComponents] AGENDA: October 21 Core Components WG Conference Call

It appears that TBG17 will not be publishing a list of proposed Core Components to be reviewed at their West Palm Beach F2F (at least not before the four week deadline to submit comments prior to the F2F).  Therefore, I suggest that we defer the work item related to reviewing the next set of TBG17 CCs.  Once the information is available, we will reinstate this work item as our highest priority (assuming no other changes).

Our second highest priority work item was to identify gaps between the approved TBG17 ACCs and OAGIS 9.  I started to do this with some of the larger, more complex ACCs (e.g. Address, Contact) and quickly discovered that unless you start with the lowest level (e.g. most granular) ACCs, it is extremely difficult to deal with the larger ACCs that use the lower level ACCs as building blocks.

My recommendation is to start with lower level ACCs such as Period. Details, Calculation. Details, Dimension. Details, Geographical Coordinate. Details, Range. Details, and Preference. Details then work our way up to larger ACCs with more complex relationships/associations.

We also have some recent decisions by ATG2 that we need to discuss.  Following is an excerpt from their October 18 meeting minutes:
 

3771	R142	Agree that R143 breaks the inheritance applicable using xsd:derivation. Using xsd:derivation is one of the fundamental principles for construction QDTs. Rule 143 should be deleted. We do not support creating QDTs that are not based on UDT through the use of xsd:derivation. If there is a business need as suggested in the comment anew UDT will have to be created
4127		No, ATG2 has previously agreed to use all capital letters for abbreviations and acronyms being part of the controlled vocabulary. Also se response to line 1705.

The first decision (Line 3771) refers to the use of xsd:derivation when creating a QDT (Qualified Data Type) from a UDT (Unqualified Data Type).  The OAGi comment was that xsd:derivation was not always possible if the QDT was based on an xsd built-in data type and the UDT was an xsd:complexType.  The ATG2 decision states that xsd:derivation must always be used when creating a QDT from a UDT.

This ruling impacts several of the QDTs already used in OAGIS 9.
 

Integer_ Numeric. Type	xsd:integer
Float_ Numeric. Type	xsd:float
Positive_ Integer_ Numeric. Type	xsd:positiveInteger
String_ Text. Type	xsd:string
Normalized_ String_ Text. Type	xsd:normalizedString
Token_ Text. Type	xsd:token
URI. Type	xsd:anyURI
Language_ Code. Type	xsd:language
Year_ Date. Type	xsd:gYear
Year_ Month_ Date. Type	xsd:gYearMonth
Duration_ Date Time. Type	xsd:duration

The second decision (Line 4127) refers to the use of "ID" vs. "Id" for abbreviations.  We had already agreed that UCC (Upper Camel Case) seemed to be more appropriate and consistent for the representation of abbreviations but it appears that ATG2 does not agree.

This decision will have a significant impact on OAGIS 9 if implemented.  Although OAGi strives to minimize the use of abbreviations, there are still several instances where abbreviations are used.  A partial list includes:
 

Doc (or DOC)	Document
Max (or MAX)	Maximum
Min (or MIN)	Minimum
Sync (or SYNC)	Synchronize

 I think this should be more than enough material for our conference call.

AGENDA:

1.  Roll Call
2.  Review and discuss recent ATG2 NDR decisions
3.  Analyze gaps between TBG17 low level ACCs and OAGIS 9

 
 
 

Our second highest priority work item was to identify gaps between the approved TBG17 ACCs and OAGIS 9.  I started to do this with some of the larger, more complex ACCs (e.g. Address, Contact) and quickly discovered that unless you start with the lowest level (e.g. most granular) ACCs, it is extremely difficult to deal with the larger ACCs that use the lower level ACCs as building blocks.

My recommendation is to start with lower level ACCs such as Period. Details, Calculation. Details, Dimension. Details, Geographical Coordinate. Details, Range. Details, and Preference. Details then work our way up to larger ACCs with more complex relationships/associations.

We also have some recent decisions by ATG2 that we need to discuss.  Following is an excerpt from their October 18 meeting minutes:
 

The first decision (Line 3771) refers to the use of xsd:derivation when creating a QDT (Qualified Data Type) from a UDT (Unqualified Data Type).  The OAGi comment was that xsd:derivation was not always possible if the QDT was based on an xsd built-in data type and the UDT was an xsd:complexType.  The ATG2 decision states that xsd:derivation must always be used when creating a QDT from a UDT.

This ruling impacts several of the QDTs already used in OAGIS 9.
 

The second decision (Line 4127) refers to the use of "ID" vs. "Id" for abbreviations.  We had already agreed that UCC (Upper Camel Case) seemed to be more appropriate and consistent for the representation of abbreviations but it appears that ATG2 does not agree.

This decision will have a significant impact on OAGIS 9 if implemented.  Although OAGi strives to minimize the use of abbreviations, there are still several instances where abbreviations are used.  A partial list includes:
 

 I think this should be more than enough material for our conference call.

AGENDA:

1.  Roll Call
2.  Review and discuss recent ATG2 NDR decisions
3.  Analyze gaps between TBG17 low level ACCs and OAGIS 9

No conference call on Tuesday, October 19.  Let's try Thursday,
October 21 at 7:30 and see what our attendance looks like.

Agenda will be posted in a couple of days.

garret

I will still have to attend on alternate weeks even if we move to
Thursdays....If we move to 10:30 PDT either day that would work for me


ajs



              garret.minakawa@o
              racle.com@Interne
              t                                                          To
                                        OAGI-CoreComponents@yahoogroups.com
              10/12/04 03:36 PM         @Internet
                                                                         cc

                                                                    Subject
                                        [OAGI-CoreComponents] RESPONSE
                                        REQUIRED: Move Conference Calls to
                                        Thursdays at 8:00 PDT??










Apparently the Tuesday 8:00 PDT calls are causing scheduling
conflicts for some of our members.

Would it be better or worse if we moved the calls to Thursdays at
8:00 PDT (15:00 UTC)?  Please let me know either way.

Thanks,

garret





Yahoo! Groups Links





[attachment "Garret.Minakawa.vcf" deleted by Alan
Stitzer/NYC-NY/US/Marsh/MMC]

Apparently the Tuesday 8:00 PDT calls are causing scheduling
conflicts for some of our members.

Would it be better or worse if we moved the calls to Thursdays at
8:00 PDT (15:00 UTC)?  Please let me know either way.

Thanks,

garret

Call was canceled since only one WG member dialed in.  Let's see
if we can make some progress via email prior to next week's call.

garret

I apologize....I will not be able to attend todays meeting.  I have a
standing ACORD meeting at 11:00 AM (eastern time).  These meetings should
end fairly soon.  Until then, I will be able to attend these meetings every
other week.


ajs

A TBG17 spreadsheet for the Document ACC has been posted to the
UN-CEFACT=>TBG17 folder.

A UML Class Diagram representing the current OAGIS implementation
of Document has been posted to the Documentation=>Document
folder.

These will be the primary reference documents for our Document.
Details ACC discussion tomorrow.

NOTE:  There are also a few other new Class Diagrams posted to
the Documentation folder.  Please review and post comments.

Thanks,

garret

• Oct 08.  TBG17 Published Version 1.0 including 19 ACCs
• Still awaiting publication of TBG17 next set of candidate ACCs
• ATG2 continuing to work through NDR open issues at weekly conference calls

We've decided that our highest priority is to review the next set of candidate ACCs from TBG17 but we still do not have the list of candidates from TBG17.  I have a pretty good idea of what ACCs will be included in the list of candidates since there was a set of "Draft 39" ACCs discussed at the McLean meeting.  The 39 ACCs are:

• Allowance Charge. Details
• Attached Equipment. Details
• Authorization. Details
• Card. Details
• Condition. Details
• Consignment. Details
• Consolidation. Details
• Currency Exchange. Details
• Damage. Details
• Delivery Terms. Details
• Despatch Details.
• Document. Details
• Equipment. Details
• Examination Result. Details
• Government Requirements. Details
• Handling Unit. Details
• Insurance. Details
• Item. Details
• Membership. Details
• Organization. Details
• Package. Details
• Price. Details
• Process. Details
• Product Classification. Details
• Product Specification. Details
• Product. Details
• Project. Details
• Qualification. Details
• Risk. Details
• Sample. Details
• Schedule. Details
• Seal. Details
• Service Item. Details
• Service Provision. Details
• Shipment. Details
• Test. Details
• Transport Means. Details
• Transport Movement. Details

We could assume the above list is valid and start the review process based on this list or continue to wait until the list is officially published by TBG17.

If we decide to go ahead with the review process, another consideration is the Category 1/Category 2 status of these candidates.  All but Document. Details are currently considered Category 2 ACCs.  This means that even though we go through an exhaustive review process of harmonizing BCCs, the final TBG17 recommendation will only contain generic BCCs for things like xxx. Identifier, xxx. Code, xxx. Text, etc.  I'm sure our work would be considered in the ABIE/BBIE harmonization process but there would not be the same sense of priority for submitting input into that process since the deadline would be some time after December, 2004.

It is also possible that some of the Category 2 ACCs may be reclassified into Category 1.  If so, BCC level harmonization would be extremely important.  Unfortunately, we have no way of knowing which ACCs are the true TBG17 candidates or which of the candidates will end up as Category 1's.  This makes scheduling and prioritizing very, very difficult.

My best suggestion at this point is to move forward with a review of the next candidate ACCs since there is only 3 weeks until the comment deadline.  Since Document. Details is the only one of the 39 possible candidate ACCs to have Category 1 status, I guess we should start with Document. Details for our review.

If there are no other thoughts or suggestions for agenda topics, I will try to post some materials about Document. Details prior to tomorrow's call.

As mentioned in the Updates section, ATG2 is continuing to address NDR open issues but they have not reached any decisions on the remaining OAGi comments so there is still nothing new to discuss on that front.

If we have any updates from Mike Rowell about the open issues in our CCTS Implementation Rules document (or any other Core Components issue), we'll also set aside some agenda time for those updates.

Agenda:

1.  Roll Call

2.  Review of October 5 Call/Minutes

3.  Open Issues Update from Mike Rowell (if available)

4.  Review of Document. Details candidate ACC
 
 
 
 
 
 
 
 

Some hints and preliminary materials here:

http://xml.coverpages.org/namesAndAddresses.html#upu-postCode

http://xml.coverpages.org/ni2003-06-17-a.html
"Universal Postal Union Publishes Approved International Address
Standard UPU S42-1"

http://www.upu.int/post_code/en/address_elements_en.pdf
"Address elements" - This UPU notice (apparently from February 2004)
says

"The International Bureau is currently compiling a list of all the
elements that may be included in international addresses, on the basis of
model addresses
collected from all the UPU member countries...."

Please send updated information if any is available.

Robin Cover

=================================================================

On Mon, 11 Oct 2004, Garret Minakawa wrote:

> Fred,
>
> Where can we get a copy of the UPU Address standard?
>
> Thanks,
>
> garret
>
>
> Garret Minakawa wrote:
>
> >  Forwarding for Fred.
> >
> > "Fred Blommestein, van" wrote:
> >
> > > Garret,
> > >
> > > When introducing a mechanism, different from the standard
> > mechanism, we create the risk not to be compatible with
> > communities that do not adopt that special mechanism. I doubt
> > that with a language code on address level you can do
> > semantically more than with one at the level of each BCC. Of
> > course, in internal databases the language code can be at the
> > record level, being mapped to the BBIE's at translation time.
> > Performance, imo, is hardly an issue.
> > >
> > > Then the example. First I wonder if the address example can
> > be generalised. Second I have my doubts even whether the
> > address example holds. The Universal Postal Union prescribes
> > for instance that the name of the country of the adressee is
> > either put in the language of the sender's country, or in
> > English. Either way the language of the country name can differ
> > from the language of the street name, which is in the adressee
> > language. In some countries (Belgium, Brussels) a street name
> > may be spelled in two languages. If I would transfer such an
> > address to update the address book of my trading partner, I
> > would repeat only the street name in both languages. I would
> > not repeat the total address as I want to update one, and not
> > two, address(es).
> > >
> > > Be careful not to make the same mistake Microsoft did, when
> > they assumed in Word that a document is always in one language.
> > My documents are frequently a mix of Dutch and English. The
> > spell checker then is confused. Europeans are weird people with
> > their attitude towards languages.
> > >
> > > Fred
> > >
> > >         -----Original Message-----
> > >         From: Garret Minakawa
> > [mailto:garret.minakawa@...]
> > >         Sent: Fri 08/10/2004 22:01
> > >         To: OAGI-CoreComponents
> > >         Cc:
> > >         Subject: [OAGI-CoreComponents] QUESTION:
> > Component-Level Translation
> > >
> > >
> > >
> > >         Last year we discussed the concept of language
> > translation at the
> > >         component level rather than the data element level.
> > I'd like to
> > >         verify if we still agree with this concept.
> > >
> > >         Using the Address component as an example, we
> > concluded it was
> > >         unlikely that one part of an address would be
> > represented in one
> > >         language while another part was in a different
> > language.
> > >
> > >         Since Address is made up of several Text. Type based
> > BCCs, we
> > >         thought it was unnecessary to include the attribute
> > "languageId"
> > >         for each of the Text BCCs.  Instead, we would make
> > "languageId" a
> > >         BCC of Address and not an attribute of each Text BCC
> > in Address.
> > >
> > >         The result of this approach is to change each of the
> > Text BCCs
> > >         from type=TextType to type=StringType (or some other
> > QDT
> > >         restriction of Text that removes the Supplemental
> > Components).
> > >
> > >         Does this still make sense?  Do we want to replicate
> > this
> > >         approach for other components?
> > >
> > >         Thanks,
> > >
> > >         garret
> > >
> > >
> > >
> > >
> > >
> > >         Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> >
> >                    Yahoo! Groups Sponsor
>                         ADVERTISEMENT
>                          [click here]
>
> >
> > ---------------------------------------------------------------
> > Yahoo! Groups Links
> >
> >    * To visit your group on the web, go to:
> >      http://groups.yahoo.com/group/OAGI-CoreComponents/
> >
> >    * To unsubscribe from this group, send an email to:
> >      OAGI-CoreComponents-unsubscribe@yahoogroups.com
> >
> >    * Your use of Yahoo! Groups is subject to the Yahoo! Terms
> >      of Service.
> >
>

--

Where can we get a copy of the UPU Address standard?

Thanks,

garret
 

Garret Minakawa wrote:

 Forwarding for Fred.

"Fred Blommestein, van" wrote:

> Garret,
>
> When introducing a mechanism, different from the standard mechanism, we create the risk not to be compatible with communities that do not adopt that special mechanism. I doubt that with a language code on address level you can do semantically more than with one at the level of each BCC. Of course, in internal databases the language code can be at the record level, being mapped to the BBIE's at translation time. Performance, imo, is hardly an issue.
>
> Then the example. First I wonder if the address example can be generalised. Second I have my doubts even whether the address example holds. The Universal Postal Union prescribes for instance that the name of the country of the adressee is either put in the language of the sender's country, or in English. Either way the language of the country name can differ from the language of the street name, which is in the adressee language. In some countries (Belgium, Brussels) a street name may be spelled in two languages. If I would transfer such an address to update the address book of my trading partner, I would repeat only the street name in both languages. I would not repeat the total address as I want to update one, and not two, address(es).
>
> Be careful not to make the same mistake Microsoft did, when they assumed in Word that a document is always in one language. My documents are frequently a mix of Dutch and English. The spell checker then is confused. Europeans are weird people with their attitude towards languages.
>
> Fred
>
>         -----Original Message-----
>         From: Garret Minakawa [mailto:garret.minakawa@...]
>         Sent: Fri 08/10/2004 22:01
>         To: OAGI-CoreComponents
>         Cc:
>         Subject: [OAGI-CoreComponents] QUESTION: Component-Level Translation
>
>
>
>         Last year we discussed the concept of language translation at the
>         component level rather than the data element level.  I'd like to
>         verify if we still agree with this concept.
>
>         Using the Address component as an example, we concluded it was
>         unlikely that one part of an address would be represented in one
>         language while another part was in a different language.
>
>         Since Address is made up of several Text. Type based BCCs, we
>         thought it was unnecessary to include the attribute "languageId"
>         for each of the Text BCCs.  Instead, we would make "languageId" a
>         BCC of Address and not an attribute of each Text BCC in Address.
>
>         The result of this approach is to change each of the Text BCCs
>         from type=TextType to type=StringType (or some other QDT
>         restriction of Text that removes the Supplemental Components).
>
>         Does this still make sense?  Do we want to replicate this
>         approach for other components?
>
>         Thanks,
>
>         garret
>
>
>
>
>
>         Yahoo! Groups Links
>
>
>
>
>

garret

Garret Minakawa wrote:

 FYI
 

Stig Korsgaard wrote:

> Dear all,
>
> After some final quality assurance and editing I am pleased officially to release the first 19 ACC´s as promised at the end of the Forum meeting in McLean.
>
> Please be aware that beside from reaching this landmark in TBG17, this also means that with the first official set of ACC´s all future submissions to TBG17, will have to take those into account when making a submission that in parts or fully includes these ACC´s. That in fact means that any submission coming in related to those 19 should be in the form of change requests.
>
> In addition I have included the announced 1.0 version of the following TBG17 documents:
>
> Submission Guidelines and Procedures
> Submission Assessment Checklist
> Submission Template
> <<TBG17 Submission Guidelines and Procedures v1pt00.doc>> <<TBG17 Submission assessment checklist 1pt0.doc>> <<TBG17 Submission Template v1pt00.xls>>
>
> Best Regards
>
> Stig Korsgaard
> Chair TBG17
> M.Sc.E Standardisation Manager
> Tel:    +45 3370 1083
> Cell:   +45 2725 9083
> Mail:   stk@...
>
> Danish Bankers Association
> Amaliegade 7
> DK-1256 Copenhagen K
> Tel:    3370 1000
> Fax:    3393 0260
> mail@...
> www.finansraadet.dk
>
>   -----------------------------------------------------------------
>                                                    Name: TBG17 CC Library Version 1_081004.xls
>                                                    Type: Microsoft Excel Worksheet (application/vnd.ms-excel)
>    TBG17 CC Library Version 1_081004.xls       Encoding: base64
>                                             Description: TBG17 CC Library Version 1_081004.xls
>                                         Download Status: Not downloaded with message
>
>                                                                    Name: TBG17 Submission Guidelines and Procedures v1pt00.doc
>                                                                    Type: Microsoft Word Document (application/msword)
>    TBG17 Submission Guidelines and Procedures v1pt00.doc       Encoding: base64
>                                                             Description: TBG17 Submission Guidelines and Procedures v1pt00.doc
>                                                         Download Status: Not downloaded with message
>
>                                                             Name: TBG17 Submission assessment checklist 1pt0.doc
>                                                             Type: Microsoft Word Document (application/msword)
>    TBG17 Submission assessment checklist 1pt0.doc       Encoding: base64
>                                                      Description: TBG17 Submission assessment checklist 1pt0.doc
>                                                  Download Status: Not downloaded with message
>
>                                                   Name: TBG17 Submission Template v1pt00.xls
>                                                   Type: Microsoft Excel Worksheet (application/vnd.ms-excel)
>    TBG17 Submission Template v1pt00.xls       Encoding: base64
>                                            Description: TBG17 Submission Template v1pt00.xls
>                                        Download Status: Not downloaded with message
>
>   -----------------------------------------------------------------
>
> ---
> You are currently subscribed to un-cefact-tbg17 as: garret.minakawa@....
> To unsubscribe send a blank email to leave-un-cefact-tbg17-52261O@...

FYI


Stig Korsgaard wrote:

> Dear all,
>
> After some final quality assurance and editing I am pleased officially to
release the first 19 ACC´s as promised at the end of the Forum meeting in
McLean.
>
> Please be aware that beside from reaching this landmark in TBG17, this also
means that with the first official set of ACC´s all future submissions to
TBG17, will have to take those into account when making a submission that in
parts or fully includes these ACC´s. That in fact means that any submission
coming in related to those 19 should be in the form of change requests.
>
> In addition I have included the announced 1.0 version of the following TBG17
documents:
>
> Submission Guidelines and Procedures
> Submission Assessment Checklist
> Submission Template
> <<TBG17 Submission Guidelines and Procedures v1pt00.doc>> <<TBG17 Submission
assessment checklist 1pt0.doc>> <<TBG17 Submission Template v1pt00.xls>>
>
> Best Regards
>
> Stig Korsgaard
> Chair TBG17
> M.Sc.E Standardisation Manager
> Tel:    +45 3370 1083
> Cell:   +45 2725 9083
> Mail:   stk@...
>
> Danish Bankers Association
> Amaliegade 7
> DK-1256 Copenhagen K
> Tel:    3370 1000
> Fax:    3393 0260
> mail@...
> www.finansraadet.dk
>
>   -----------------------------------------------------------------
>                                                    Name: TBG17 CC Library
Version 1_081004.xls
>                                                    Type: Microsoft Excel
Worksheet (application/vnd.ms-excel)
>    TBG17 CC Library Version 1_081004.xls       Encoding: base64
>                                             Description: TBG17 CC Library
Version 1_081004.xls
>                                         Download Status: Not downloaded with
message
>
>                                                                    Name: TBG17
Submission Guidelines and Procedures v1pt00.doc
>                                                                    Type:
Microsoft Word Document (application/msword)
>    TBG17 Submission Guidelines and Procedures v1pt00.doc       Encoding:
base64
>                                                             Description: TBG17
Submission Guidelines and Procedures v1pt00.doc
>                                                         Download Status: Not
downloaded with message
>
>                                                             Name: TBG17
Submission assessment checklist 1pt0.doc
>                                                             Type: Microsoft
Word Document (application/msword)
>    TBG17 Submission assessment checklist 1pt0.doc       Encoding: base64
>                                                      Description: TBG17
Submission assessment checklist 1pt0.doc
>                                                  Download Status: Not
downloaded with message
>
>                                                   Name: TBG17 Submission
Template v1pt00.xls
>                                                   Type: Microsoft Excel
Worksheet (application/vnd.ms-excel)
>    TBG17 Submission Template v1pt00.xls       Encoding: base64
>                                            Description: TBG17 Submission
Template v1pt00.xls
>                                        Download Status: Not downloaded with
message
>
>   -----------------------------------------------------------------
>
> ---
> You are currently subscribed to un-cefact-tbg17 as:
garret.minakawa@....
> To unsubscribe send a blank email to
leave-un-cefact-tbg17-52261O@...

Forwarding for Fred.

"Fred Blommestein, van" wrote:

> Garret,
>
> When introducing a mechanism, different from the standard mechanism, we create
the risk not to be compatible with communities that do not adopt that special
mechanism. I doubt that with a language code on address level you can do
semantically more than with one at the level of each BCC. Of course, in internal
databases the language code can be at the record level, being mapped to the
BBIE's at translation time. Performance, imo, is hardly an issue.
>
> Then the example. First I wonder if the address example can be generalised.
Second I have my doubts even whether the address example holds. The Universal
Postal Union prescribes for instance that the name of the country of the
adressee is either put in the language of the sender's country, or in English.
Either way the language of the country name can differ from the language of the
street name, which is in the adressee language. In some countries (Belgium,
Brussels) a street name may be spelled in two languages. If I would transfer
such an address to update the address book of my trading partner, I would repeat
only the street name in both languages. I would not repeat the total address as
I want to update one, and not two, address(es).
>
> Be careful not to make the same mistake Microsoft did, when they assumed in
Word that a document is always in one language. My documents are frequently a
mix of Dutch and English. The spell checker then is confused. Europeans are
weird people with their attitude towards languages.
>
> Fred
>
>         -----Original Message-----
>         From: Garret Minakawa [mailto:garret.minakawa@...]
>         Sent: Fri 08/10/2004 22:01
>         To: OAGI-CoreComponents
>         Cc:
>         Subject: [OAGI-CoreComponents] QUESTION: Component-Level Translation
>
>
>
>         Last year we discussed the concept of language translation at the
>         component level rather than the data element level.  I'd like to
>         verify if we still agree with this concept.
>
>         Using the Address component as an example, we concluded it was
>         unlikely that one part of an address would be represented in one
>         language while another part was in a different language.
>
>         Since Address is made up of several Text. Type based BCCs, we
>         thought it was unnecessary to include the attribute "languageId"
>         for each of the Text BCCs.  Instead, we would make "languageId" a
>         BCC of Address and not an attribute of each Text BCC in Address.
>
>         The result of this approach is to change each of the Text BCCs
>         from type=TextType to type=StringType (or some other QDT
>         restriction of Text that removes the Supplemental Components).
>
>         Does this still make sense?  Do we want to replicate this
>         approach for other components?
>
>         Thanks,
>
>         garret
>
>
>
>
>
>         Yahoo! Groups Links
>
>
>
>
>

Garret,

let me jump in quickly and say that, on the surface, this looks like a much
better idea than having each ".text: bcc have its own language identifier.

I agree with the assessment that it is highly unlikely that within
something like address, more than one language would be needed.


ajs



              garret.minakawa@o
              racle.com@Interne
              t                                                          To
                                        OAGI-CoreComponents@yahoogroups.com
              10/08/04 04:01 PM         @Internet
                                                                         cc

                                                                    Subject
                                        [OAGI-CoreComponents] QUESTION:
                                        Component-Level Translation










Last year we discussed the concept of language translation at the
component level rather than the data element level.  I'd like to
verify if we still agree with this concept.

Using the Address component as an example, we concluded it was
unlikely that one part of an address would be represented in one
language while another part was in a different language.

Since Address is made up of several Text. Type based BCCs, we
thought it was unnecessary to include the attribute "languageId"
for each of the Text BCCs.  Instead, we would make "languageId" a
BCC of Address and not an attribute of each Text BCC in Address.

The result of this approach is to change each of the Text BCCs
from type=TextType to type=StringType (or some other QDT
restriction of Text that removes the Supplemental Components).

Does this still make sense?  Do we want to replicate this
approach for other components?

Thanks,

garret





Yahoo! Groups Links





[attachment "Garret.Minakawa.vcf" deleted by Alan
Stitzer/NYC-NY/US/Marsh/MMC]

Last year we discussed the concept of language translation at the
component level rather than the data element level.  I'd like to
verify if we still agree with this concept.

Using the Address component as an example, we concluded it was
unlikely that one part of an address would be represented in one
language while another part was in a different language.

Since Address is made up of several Text. Type based BCCs, we
thought it was unnecessary to include the attribute "languageId"
for each of the Text BCCs.  Instead, we would make "languageId" a
BCC of Address and not an attribute of each Text BCC in Address.

The result of this approach is to change each of the Text BCCs
from type=TextType to type=StringType (or some other QDT
restriction of Text that removes the Supplemental Components).

Does this still make sense?  Do we want to replicate this
approach for other components?

Thanks,

garret

I've already received feedback from a few different people so I
thought this should go to the entire group.

I don't know why YahooGroups didn't deliver the meeting reminder
until after the meeting finished but in order to prevent a
similar situation in the future, I've changed reminders for all
future meetings to 1 day prior and 2 hours prior (so now there
are no excuses ;-)).

I've also included both local time (PDT) and UTC/GMT in any text
that refers to a meeting time.  I think YahooGroups does adjust
for your local time zone but I may be mistaken.

If you have any additional suggestions, please let me know.

Thanks,

garret

Garret Minakawa
Mike Rowell
Sylvia Webb

Minutes:

• No recording available for today's call since there were only two attendees until 15 minutes into the call.
• Reviewed CCTS-ImplementationRules.doc
• All sections of the document were agreed upon except for Open Issues
• Open Issue 1 - Annotations.  Communicated WG's recommendation to adopt ATG2 Annotation scheme to Mike Rowell.  Mike will review and issue a final decision.  A spreadsheet summary of the ATG2 Annotation scheme is now available on the WG site as "ATG Annotations.xls"
• Open Issue 2 - Code Lists and Identifier Lists.  Issue deferred until after Architecture WG call later today.
• Open Issue 3 - Binary Object. Type - mimeCode=required.  Still some questions remaining about why ATG2 wants this to be required.  If it is for decoding purposes, what is the difference between mimeCode and encodingCode?  Should encodingCode be required instead of mimeCode?  Garret to request additional clarification from ATG2.

Garret,

sorry for missing the meeting today...had to finish up with some ACORD
stuff.

If you could get the reminder out two hours in advance, that would be
better....the email did not get to my inbox until 1 hour after the meeting
had ended....


thanks..


ajs



              OAGI-CoreComponen
              ts@...
              m@Internet                                                 To
                                        OAGI-CoreComponents@yahoogroups.com
              10/05/04 12:24 PM         @Internet
                                                                         cc

                                                                    Subject
                                        [OAGI-CoreComponents] Core
                                        Components WG Conference Call,
                                        10/5/2004, 8:00 am











  Reminder from the Calendar of OAGI-CoreComponents
  http://groups.yahoo.com/group/OAGI-CoreComponents/cal

Core Components WG Conference Call
Tuesday October 5, 2004
8:00 am - 9:00 am
(This event does not repeat.)

Notes:
Dial In: 1-888-967-2253 (U.S.)
1-650-607-2253 (International)
Conference ID: 850749
Password: 947058


Send a Yahoo! Greeting at:
  http://greetings.yahoo.com

Set up birthday reminders!
 
http://us.rd.yahoo.com/cal_us/rem/?http://groups.yahoo.com/group/OAGI-CoreCompon\
ents/cal?v=9&evt_type=13

Copyright 2004 Yahoo! Inc. All Rights Reserved.
  http://www.yahoo.com

Privacy Policy:
  http://privacy.yahoo.com/

Terms of Service:
  http://docs.yahoo.com/info/terms/

[attachment "C.htm" deleted by Alan Stitzer/NYC-NY/US/Marsh/MMC]

TBG17 has not yet published their next set of Core Components for
comment so I would like to recommend that we review the document
"CCTS-ImplementationRules.zip" at tomorrow's conference call.

This document has just been posted to the WG site.  It contains a
summary of the implementation decisions we've made regarding
Unqualified Data Types and Qualified Data Types.  Some of these
will be a review of things we've already covered but there will
also be a few new issues that deserve some discussion.  We will
also try to work through some of the open issues identified in
this document.

Thanks,

garret