OASIS ebXML Messaging Services TC

Schema-Specification normative preference wasRE: [ebxml-msg]Issue73:http://schemas.xmlsoap.org/soap/envelopenamespace

  • 1.  Schema-Specification normative preference wasRE: [ebxml-msg]Issue73:http://schemas.xmlsoap.org/soap/envelopenamespace

    Posted 02-18-2002 10:41
    From a pragmatic point of view, if
    one side is checking schema validity, and the other says
    it is following the spec. and produces schema-invalid 
    XML, then interoperability will be very hard to obtain.
    In effect, schema validity checking would have to be 
    turned off for interoperability!?!
     
    This would probably be a bad thing. So "between
    specification versions," I think
    the schema should take precedence,
    if we miss something or, more wackily, 
    decide not to fix known discrepancies. 
    
    Small discrepancies might be handled by interim schema fixes,
    with a fixed URL, but potentially variable schema.
    (I think that could work, anyway; if we had a URN
    resolver service it might be easier. But there
    seem to be no best current practices for URN 
    resolution services.)
    
    With a provision for updates at a fixed, announced
    location, at least implementers could be told
    to periodically check for a fixed schema to
    resolve interop. issues.
    
    I am not wild about this proposal--it has 
    all the elegance of CRL lists for PKI, 
    but it might be OK in the interim 
    for PSI (public schema infrastructure).
    
    A RegRep mechanism might also be available.
    Any one have something better to handle
    "between specification" schema fixes?
    
    My $.02.