UBL Naming and Design Rules SC

Clarification of Containership rules

  • 1.  Clarification of Containership rules

    Posted 07-02-2003 01:51
    Following our phone conference yesterday, I agreed to provide you with 
    some guidelines that will enable you to refine the current position 
    paper and NDR Rules on this matter.
    
    The following have agreed to assist in your work, to provide examples 
    and comments on your drafts.
    
    Stephen Green (stephen_green@bristol-city.gov.uk)
    Tony Coates (abcoates@londonmarketsystems.com)
    
    The timeframe for completion of this task should be Tuesday July 8th - 
    the LC team have a meeting at 08:00 California time at which we would 
    like to table your findings.
    
    Scope of Work:
    -------
    Currently the NDR Checklist contains two rules:
    1. All documents shall have a container for metadata and which proceeds 
    the body of the document and is named "Head" _____________. (anything 
    but header)
    and
    2. All elements with a cardinality of 1..n, (and lack a qualifying 
    structure) must be contained by a list container named "(name of 
    repeating element)List", which has a cardinality of 1..1.
    
    These rules require refinement and clarification.  Your mission (should 
    you accept it), is to present a revised set of rules with documentation 
    and examples that can be unambiguously and consistently implementable 
    across the UBL Library.  To assist in this I have tried to summarise the 
    points as a  problem statement...
    
    Problem Statement:
    --------------------
    The LC group have had difficulty in implementing these rules 
    unambiguously for all document types and structures.  We understand that 
    these rules should not be dependent on semantics or business context and 
    this prevents us from automatic generating them from our models.
    
    Some issues (and these are not all) we have encountered are:
    * Documents which have more than one 1:many association at the 
    "Header"/root level.  That is, where not only the "lines" can repeat 
    indefinitely, such as Invoice with AllowanceCharge, 
    OrderDocumentIdentification, TaxTotal.  We are concerned that this 
    portends more ambiguities when we deal with documents that are not 
    simple Header+LineItem(s),structure such as the transportation 
    documents.  This is already seen in the DespatchAdvice, where the 
    document may be viewed as Header+TransportHandlingUnit(s) or 
    Header+Goods. A further compelxity is also seen in the DespatchAdvice 
    where we have a document that may contain the sub-structure of other 
    documents (in this case the OrderedItem(s)).
    * If we implement the  "(name of repeating element)List" rule, what is 
    done about:
        (a) 0..n structures
        (b) extensions/derivations/customizations that chnage the 
    cardinality of an ABIE (e.g. make an optional ABIE, mandatory)
    Do we want additional levels of nesting that may hold empty containers, etc?
    
    -- 
    regards
    tim mcgrath
    phone: +618 93352228  
    postal: po box 1289   fremantle    western australia 6160