OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [ubl-ndrsc] New recommendations/comments from the NDR SC

The raw minutes of the NDR and CM SC meetings last week (some of which 
cover joint sessions with the LC SC) can be found at:


I was tasked to let the LC SC know about NDR SC recommendations that 
we officially approved last week:

Native Context:

Ron Schuldt has written up a paper making his case for UDEF attributes 
on UBL constructs.  The paper can be found at the NDR portal, 
http://www.oasis-open.org/committees/ubl/ndrsc/.  (The paper expects a 
disposition from the LC SC, though most of the discussion we've had on 
the matter so far has been in the NDR SC.)  After discussion, the NDR 
SC approved the following motion: "Refer Ron's proposal to the LC SC 
with a recommendation that it not be adopted as part of core UBL but 
rather considered as a possible extension that external
parties could create."

Number of Document Types:

As we mentioned in our final joint session last Friday, the NDR SC 
supports a bias towards creating more document types ("instance 
roots", "message types", "top-level elements") for the semantic 
clarity and validation power it brings.  We approved the following 
motion: "Ratify the one-doctype-per-transmission principle as
stated in the UBL Planning report and the modnamver paper."

Comments on the 0.64 Distribution:

Following are the comments we've collected to date (we know there will 
be more) on the 0.64 distribution made available last week.

Contact details: ubl-ndrsc@lists.oasis-open.org
Date: 26 March 2002
Artifact/version reviewed: 0.64 spreadsheet

UBL UID: General comment.

Comment: The spreadsheet is missing System
Constraints Context and Supporting Role Context.

Proposal: Add these columns.

References: None.

UBL UID: General comment.

Comment: We note that there is no capturing of precision (for numeric 
   formats) and other similar constraints, such as string lengths. 
This will need to be captured at a later date.

Proposal: Figure out a methodology for capturing this information and 
then go through the structures capturing it.

References: None.

UBL UID: General comment.

Comment: We think we'll need a rule eventually about how relationships 
(extra-hierarchical) get encoded in XML. E.g., ID/IDREF, URI, 
application-specific IDs, linkbases, etc. We wonder if the LCSC is 
sufficiently considering its requirements about such relationships.

Proposal: Looking for such relationships should probably be in the 
methodology somewhere.  The following template of information that 
could be collected about each link is adapted from "Developing SGML DTDs":

- Type of relationship/meaning expressed
- What source(s) and target(s) are being associated
- Directionality (e.g., is it a two-way relationship?)
- How the link gets used in processing

This is probably enough information for the NDR SC to get started 
recommending one or more linking strategies in the actual schema modules.

References: Developing SGML DTDs, ISBN 0-13-309881-8

UBL UID: General comment.

Comment: Do not use specific words that have different meanings in 
different industries (like check-in/check-out, which are the opposite 
in hotel and rental cars); instead, go for general terms (e.g. 
period-start, period-end, etc.)

Proposal: See above.

References: None.

UBL UID: UBL000002 (occurs other places as well)

Comment: UBL Name should be "BuyerID" because you're supposed to fold 
the property term into the representation term when they're similar, 
and you're supposed to truncate Identifier to ID.

Proposal: Change name here to "BuyerID" and check other similar cases.

References: None.

UBL UID: UBL000017

Comment: Is there a need to provide rules for constructing models that 
   allow for either a small-grained structure (address postbox ID 
etc.) and a large-grained structure (address line 1 etc.)?

Proposal: Consider the option of allowing more "blob"-like addresses 
that call out only a few specific pieces of information.  This could 
possibly be done as a "choice group" beneath the main address 
structure, so that both options are always available when an address 
is being supplied.  However, if one of the options needs to be removed 
in certain contexts, then it is more appropriate to make two object 
classes for different kinds of addresses and pushing the optionality 
"up" a level.  (We are happy to discuss this kind of modeling further 
with the LC SC.)

References: None.

UBL UID: UBL000017 (occurs other places as well)

Comment: The structure seems unusually flat by XML, OO, and database 
standards. While we're not against the use of sequences, we suspect 
that developers may find it more useful to have collections of 
elements that are "rolled up" into container elements at an 
intermediate level (for example, rows 30-31 for country sub- 
entities).  The classic chunking standard for human memory is 7 +/- 2, 
and standard operating procedure for software developers and database 
designers is to use this standard.

Proposal: Consider intermediate containership for addresses, and 
possibly other structures with long flat sequences.

References: None.

UBL UID: UBL000017 (occurs other places as well)

Comment: We note that there's a lot of optionality of elements. For 
example, there's nothing required in Address. Are there 
interoperability consequences to this?  If the context methodology is 
sufficient, is it better to allow optional elements to be made 
required or better to allow removal of elements?  Would intermediate 
containers help this situation at all (e.g., you can make the 
container optional and the contents required)? How is the "sweet spot" 
determined on this?  As another example, we know that there will be 
other kinds of things that we want to consider line items, but each
kind will have a different combination/cardinality of contents.  We 
want to have a rule that the structures have the maximum number of 
required contents, and where splitting the structure into multiples 
will help, it should generally be done.

Example: Line items contain at least quantity (1), part number (2), 
and description (3). In certain stages of the process, they also 
contain price information (4), tax information (5), and shipping 
information (6).  So you have really four kinds of line item: order, 
invoice, shipping, and catalog.  These should be considered different 

Proposal: Consider intermediate containership in order to require 
information that is truly required, assisting interoperability.  Also, 
consider splitting some structures into multiples for the same benefits.

References: None.

UBL UID: UBL000345

Comment: The choice of property term seems to obfuscate the desired 
semantic here.  This is supposed to identify the order from the 
buyer's perspective; something like "Buyer's Order ID" would convey 
this better, though possessives in English are suspect for tag naming.

Proposal: Consider a different name here.

References: None.

UBL UID: UBL000338 (as an example)

Comment: The LineItem content in the Order model, and likely many 
(most? all?) other things that have 0..n or 1..n cardinality, could 
usefully be grouped in a containing structure (the xCBL ListOf... 
design pattern).  For some (all?) 0..n things, it might be desirable 
to make the container 0..1 and the contents 1..n.

Proposal: Consider adding a "list of" notion in order to capture 
series of like things and strengthen validation.

References: None.

Respectfully submitted,

	Eve Maler
	for the NDR SC

Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC