UBL Naming and Design Rules SC

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

  • 1.  [ubl-ndrsc] New recommendations/comments from the NDR SC

    Posted 03-26-2002 09:06
     MHonArc v2.5.2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    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:
    
       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
    
    -- 
    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