Re: [ubl-lcsc] New recommendations/comments from the NDR SC

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

am i to  assume that you will be presenting to complete list to us as 
part of the review process?


Eve L. Maler wrote:

> 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:
>
>   http://lists.oasis-open.org/archives/ubl-ndrsc/200203/msg00028.html
>
> 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.
>
> Reviewer: OASIS UBL NDR SC
> 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 
> rows.
>
> 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
>

-- 
regards
tim mcgrath
fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142