Re: [ubl] 1.0 Issues list

[Tim McGrath <tmcgrath@portcomm.com.au>]

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?

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

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.

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.

finally I would like to add few more issues to this list.

* The UML Class Diagram for the Document Components (UBL-1.0-DocumentComponents.jpg)
shows two associations between Order Line Reference and Line Reference which
do not exist.  These should be removed from the diagram (and its lo-res version
known as UBL-1.0-DocumentComponentsLoRes.jpg).

and the following from Yukinori Saito (saito-yukinori@fujielectric.co.jp)
ref: http://lists.oasis-open.org/archives/ubl/200406/msg00027.html
*  The BBIE known as "Line Item. Maximum_  Backorder. Quantity" and "Line
Item. Minimum_  Backorder. Quantity" both have definitions that use the term
customer.  as in, "the maximum quantity of an item that a customer will allow
to be back ordered.".  Customer is not a term used anywhere else in UBL.
 Suggested action is to chnage this term to Seller Party.

*  The UBL Name in the spreadsheet for two BBIEs within Order Reference are
wrong.  These are "DocumentDocumentStatusCode" and "IssueIssueDateDate".
 The formulae has not been refreshed.  Suggested action is to refresh to
formula.  NB Open Office does not always do this automatically, I don't know
why.

* The definition under the BBIE, Secondary Hazard. Extension. Text states
"identifier of additional information regarding the hazardous substance.
Can be used to identify information such as the type of regulatory requirements
that apply to a description." whereas it is not an identiifer at all.  Suggested
action is to change the definition to "additional information regarding the
hazardous substance. Can be used to specify information such as the type
of regulatory requirements that apply to a description."

* The definition under the BBIE, Transport Handling Unit. Received_ Handling
Unit Receipt Line. states "associates the Transport Handling Unit with one
or more despatch lines on a despatch advice."  which is the definition of
another BBIE. Suggested action is to change the definition to "associates
the Transport Handling Unit with one or more receipt lines on a receipt advice."

* The definition under the BBIE, Party. Party Name.  states "associates (optionally) 
the party with one or more party names" but the cardinality is 0..1 Suggested 
action is to change the definition to "associates (optionally) the party with
a party name"

* The definition under the BBIE, Party. Address.  states "associates (optionally)
the party with one or more addresses" but the cardinality is 0..1 Suggested 
action is to change the definition to "associates (optionally) the party with
an address"
 
Anne Hendry wrote:

Hi,

As per my AI from last week's coordination call, here is a spreadsheet which captures the issues raised by Chee-Kai in his mail of 25 May.  I will look further through the email to see if there are additional issues, but this should get us going at least.  If someone has anything they want to add before tomorrow's call, let me know as I'll probably find a few more myself this afternoon and send out an update tonight.

Michael, Stephen, Mavis: if you consider your investigation complete enough at this time I can add the issues raised in your comparison as best as I can glean from the email thread, but a summary would be helpful.

Thanks very much,

Anne

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl/members/leave_workgroup.php.

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160