UBL Naming and Design Rules SC

 View Only
  • 1.  Namespace & versioning

    Posted 04-28-2003 13:19
    Namespace
    =========
    
    I'm very happy with current namespace style in 0p70.  The thing
    I'm happy about is that the namespaces of each Reusable and the
    7 document classes are all different.  As all of you know that
    XML specification only require the namespace values of different 
    tagnames that carry different meanings to be *different*.
    
    With that, I'm not exactly certain if encoding a lot of information,
    such as the fact that it is an "Invoice" and not an "Order",
    and that it belongs to version "0p70" and not "0p65", etc,
    is a good or dangerous idea.  Unfortunately I cannot see what
    "dangerous" effects such packing of info within the namespace
    string have or will have at this point.  Perhaps that's the
    reason why I'm waivering a little on this aspect.
    
    The current namespace values in the documents are good to maintain,
    however, because the formula that churns them out make each
    document class have different namespace string.  This is important.
    
    One comment I read from the inputs that suggests making
    all "Order", "OrderAcknowledgement (Simple)", "OrderAcknowlegement
    (Complex)" have the same namespace is something I don't quite 
    understand.  Maybe I don't quite understand the rational in the
    NDR proposed recommendation on namespace naming as well.  
    The way it goes, it seems like if a doc class is prefixed
    with "Order", it would have to use the "Order" namespace.
    This seems strange to me as "Order" and "OrderAcknowledgement"
    are documents used by different parties (in fact, exactly
    opposing ends of the business communication).  I'm not sure why
    (and it doesn't seem to come out from the NDR paper) we're 
    aligning the namespace dimension with prefixes, instead of
    more ground/end-user oriented factors  such as the fact that
    the different doc classes are processed by different validators
    on different machines.
    
    I'm inclined to suggest that the existing one-namespace-per-
    document-class style be continued.  It's good, it's clear, and
    it's distinctive.  I'm much less inclined to pack all information
    from document type, version, and any other information into
    the namespace string.
    
    
    Version
    =======
    
    Version of UBL schema used, as well as the document type
    (ie, whether this instance is a "Order", "Invoice", etc), ought
    to be explicit, required, and stand on its own fields.
    
    Imagine the world having UBL v1.0 documents floating around,
    and now UBL v2.0 is just introduced and some systems are
    generating them but not others.  Packing version info into
    namespace will immediate cause many schema-based validators
    to throw out v2.0 since that namespace isn't known to v1.0
    validators.  It's not clear to me how we can have a smooth 
    upgrading of systems, or gradual migration, or more importantly,
    gradual degradation where only new, unknown tags in v2.0 are
    flagged with errors on v1.0 validators.  By packing version
    in namespace strings, we run a risk of disowning the very
    flexibility of XML that allows new tags to be introduced
    without upsetting existing defined tags.
    
    Packing document type info into the namespace string likewise
    force schema-based validators to "try" each and every possible
    document class for namespace match before either concluding that
    it has a positive match on namespace to validate, or after 
    running out all possibilities, to conclude that the instance
    is unknown.  There is no need to force the validators to 
    explore a potentially huge unknown space of possible namespace
    strings if an explicit attribute, such as 
    
    	docType="Order"
    
    is clearly described in the instance.
    
    In short, it seems to me that docType and version are 
    meta-info attributes that should be in the UBL space.
    
    Looking from the recipient UBL processor point of view,
    a document is unknown and cannot be processed meaningfully
    until its version and document type are clear.  The receiving
    UBL processor only can expect that it is a UBL document,
    of any version of any doc type.  To extract these 2 pieces
    of info, it'll have to "look" for the 2 pieces of attribute
    in the so-called well-known namespace.  Thus we might need
    the instance document to have:
    
    <ublOrder:Order 
       ubl:version="1.0"
       ubl:docType="Order"
       xmlns:ublOrder="urn:oasis:names:tc:ubl:Order"
       xmlns:ubl="urn:oasis:names:tc:ubl">
       ...
    </ublOrder:Order>
    
    The well-known, version- and document-invariant namespace
    being "urn:oasis:names:tc:ubl", for example.
    
    
    
    
    Best Regards,
    Chin Chee-Kai
    SoftML
    Tel: +65-6820-2979
    Fax: +65-6743-7875
    Email: cheekai@SoftML.Net
    http://SoftML.Net/
    
    
    On Mon, 28 Apr 2003, Mavis Cournane wrote:
    
    >>The powerpoint of the Opening Sub Committee Reort for the Oasis UBL Naming
    >>and Design Rules Sub Committeee is available on the Oasis UBL NDRSC webiste
    >>at:
    >>http://www.oasis-open.org/committees/download.php/1773/UBL%20Namingand%30Des
    >>ignt%20Rules-Opening.ppt
    >>This meeting will be going on all through this week, we plan on posting
    >>minutes each night for the day's work.
    >>
    >>Regards
    >>Mavis Cournane
    >>Cognitran Ltd
    >>Co-chair UBL NDR SC
    >>
    >>