OASIS Universal Business Language (UBL) TC

 View Only

Namespace URI string implications

  • 1.  Namespace URI string implications

    Posted 06-06-2006 05:11
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    ubl message

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


    Subject: Namespace URI string implications


    Further to tonight's teleconference, I brought up a concern of a 
    decision Paul Thorpe and I heard in Brussels that we didn't realize 
    was in the works and that has critical deployment ramifications that 
    I feel the committee should discuss.
    
    But I gather from Jon's comments in the call, this is a 
    long-hashed-out issue and I run the risk of angering a number of 
    members by bringing this up.  But I don't believe I had been party to 
    the discussion earlier as this was a surprise to me, so belatedly 
    I'll bring up the issue that Paul raised and an issue that I've 
    determined from documenting my proposed subsetting and extension methodologies.
    
    I don't want to put words into Paul's mouth, so I'll invite him to 
    comment himself, but I guess that perhaps this hadn't been widely 
    known since it was news to him as well.
    
    Paul and I believe that *any* change to the document models 
    *requires* the namespace URI string to be different ... even for 
    minor changes because a 2.1 document model will have more information 
    items than a 2.0 instance ... keeping the namespace URI strings the 
    same and embedding version information will have major deployment 
    problems with respect to validation.
    
    We cannot have the same namespace string identifying the vocabularies 
    for UBL 2.0 and a modified UBL 2.1 for the following reasons 
    (probably among others but these are show-stoppers), based on the 
    premise that W3C validation associates the namespace URI string to 
    the structures of the document through the targetNamespace= property 
    in the document element of the schema ... thus, there is a strict 
    association between what the string says and the document model, 
    producing the following issues:
    
    (1) Deployment of a heterogeneous system
      - there is no way we can shut down global UBL usage of a 2.0, 
    deploy 2.1, and start the world up again
      - a system that has upgraded to 2.1 will forward what they consider 
    to be a UBL valid instance, since it validates in their system 
    against the published 2.1 schemas, to a 2.0 system, and the 2.0 
    system will reject it for non-compliance to the UBL schemas they are 
    using that are
      - I'm told there is a parallel with ASN.1 ... Paul has customers 
    with networks of thousands of users of heterogeneous implementations 
    of the ASN.1 equivalent of a document model and they must be uniquely 
    identified for the high-speed algorithms in the interface chips to 
    accurately accept and reject properly-formed ASN.1 messages
    
    (2) The front-line interface to many programs is validation
      - one comment in Brussels was that the version information is to be 
    found inside the instance
      - there are program interfaces to XML that "pre-compile" the W3C 
    Schema expression into artefacts such as Java classes and C# data structures
      - I understand such interfaces are keyed on the namespace URI 
    strings based on the targetNamespace= property ... perhaps someone 
    can tell me otherwise, but if I compile a cac:Party into a C# data 
    structure and the data stream arrives with a matching target 
    namespace but more information items that my data structures can 
    support, can someone tell me what the program does with the extra 
    information items?
      - the premise of blind XML document interchange is that the 
    receiver validates what the sender sends so that the receiver's 
    program knows what the sender is sending is acceptable ... if we 
    expect programs to go into an XML document and examine the version 
    information item, an instance won't even get past the gatekeeper of 
    W3C Schema Validation if a 2.1 instance is sent to a 2.0 
    implementation because the 2.1 namespace is interpreted as having the 
    2.0 document model and the presence of the 2.1 information items 
    kills the data flow before the program even sees the instance
    
    A possible mitigation as I write this is to use a 2.1 namespace URI 
    string but us it *only on the elements that are new to version 2.1* 
    and not on the document element.  But this will mean we must 
    introduce a namespace-based exorcism step in the deployment of UBL 
    applications where a "filter" step that is engaged after receipt of a 
    message will preserve information items in the UBL namespaces that 
    are supported by a given deployment, and elide the information items 
    that are not supported.  Then, schema validation will proceed without 
    "tripping" over the information items that are not expected, and it 
    will be able to find the version information in the structure because 
    the filtered structure will have passed validation.
    
    But it means that we still need to introduce new namespace URI 
    strings in order to distinguish the new information items of 2.1 from 
    the old information items of 2.0.
    
    Paul and I heard of the decision and when we tried to bring it up on 
    the Friday there was insufficient time to talk about it before I and 
    others had to leave for the airport.
    
    If UBL members still believe that we can have one namespace URI 
    string for two different document structure declarations, could you 
    please help us understand how the two issues above are addressed.
    
    Paul, could you please add your own spin on this?
    
    I've written this very quickly in order to get the debate started ... 
    I apologize if I've missed something obvious.  On the call it seemed 
    important that this be discussed quickly.
    
    Thanks!
    
    . . . . . . . . . . . . Ken
    
    --
    Registration open for XSLT/XSL-FO training: Wash.,DC 2006-06-12/16
    Also for XSL-FO/XSLT/XML training:    Birmingham, UK 2006-07-04/13
    Also for XSL-FO/XSLT training:    Minneapolis, MN 2006-07-31/08-04
    Also for XML/XSLT/XSL-FO/UBL training: Varo,Denmark 06-09-25/10-06
    World-wide corporate, govt. & user group UBL, XSL, & XML training.
    G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
    Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
    Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
    Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/o/bc
    Legal business disclaimers:  http://www.CraneSoftwrights.com/legal
    
    


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