RE: [ubl] 1.0 Issues list

[<MCRAWFORD@lmi.org>]

-----Original Message-----
From: Tim McGrath [mailto:tmcgrath@portcomm.com.au]
Sent: Tuesday, June 08, 2004 9:17 PM
To: anne.hendry@sun.com
Cc: ubl@lists.oasis-open.org
Subject: Re: [ubl] 1.0 Issues list

I have a few comments to make on these issues.

issue number 10 states as its resolution ..
"These should be better removed from the CommonBasicComponents schema.  They have not been mandated by nor referred to in CommonAggregateComponents (or its corresponding spreadsheet model), and so shouldn't be defined in CommonBasicComponents."
I thought we had debated this and decided that these are re-usable BBIEs and should be in the CBC module.  The only difference between these and other BBIEs is that we dont use them in an unqualified state - but we do re-use them.  what is more other documents or customizations of UBL may also want to re-use these.
I would have thought these things are essential to have a re-usable library - otherwise every different implementation may choose to define them differently.
What is the rationale for removing them?
[mrc] I concur with Tims assessment and believe their occurence in the CBC is correct 

issue 11 and 12 relate to the original filenames of the file haolding the values of the codes to be loaded into the schemas.  i am not sure it is really important what these are called as in  some cases we didn't even use them and we don't supply the source file anyway.  also i would have thought it is perfectly acceptable to use different source data files for code set values, so binding the filename to the code list name is not practical either.  however if it saves confusion it may be easier to leave these blank rather than imply a relationship that isn't there
[mrc] We certainly did not address these in the NDR, nor do I think we should worry about what they are called since they are non-normative.  

issue 14 impacts the issue of CCTS schemas.  the data model for Binary Object is wrong in UBL, according to the original schemas from Gunther and Garrett/OAG's revised ones.  in fact, the Binary Object should be all supplementary components except for MimeCode.  This was my mistake when i built the model.  So before we make the schema fit the model, we should correct the model.
[mrc] I will anxiously await the revised model.  

issue 16, 17, 18 and 19 all relate to the abbreviation of UniformResourceID to URI and reflect an ongoing issue about the normative UBL Name and Dictionary Entry Name for UBL.  It is important to remember that only the schemas have the normative names.  The UBL Names and Dictionary Entry Names calculated in the spreadsheets are given for guidance of the modelers only (that is why their headings are greyed out - they do not get transferred into the schemas).  The columns with yellow headings are 'normative' in that their values must appear 'as-is' in the schemas.  
Unfortunately spreadsheet formulaes are just not good enough to define all our rules.  One rule we did not build into the spreadheet formulas was the use of all legitimate abbreviations.  The formulaes just got too hard to manage.  The formula did abbreviate Identifier to ID but not Uniform Resource Identifier to URI (which it should have done).  So in this case the schemas are correct and the spreadsheet names are not.  My suggested action would be to manually correct the UBL Name and Dictionary Entry Names in the spreadsheets for these few cases.
[mrc] concur. 

 

Mark
Mark Crawford
Senior Research Fellow - LMI XML Lead
W3C Advisory Committee, OASIS, RosettaNet Representative
Vice Chair - OASIS UBL TC & Chair Naming and Design Rules Subcommittee
Chair - UN/CEFACT XML Syntax Working Group
Editor - UN/CEFACT Core Components
______
LMI Government Consulting
2000 Corporate Ridge, McLean, VA 22102-7805
(703) 917-7177 Fax (703) 917-7481
Wireless (703) 655-4810
mcrawford@lmi.org
<http://www.lmi.org/>
The opportunity to make a difference has never been greater