OASIS ebXML Messaging Services TC

 View Only

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

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

    Posted 02-18-2002 23:13
    The schema being a normative part of the spec would help those of us 
    implementing it quite a bit.  I am not offering a solution for the 
    obvious protocol problems involved with having two separate ways of 
    interpreting ebMS, just stating a objective point of view.  Sometimes 
    specification language is difficult to interpret if you weren't involved 
    in the specification process, so having a approved schema to fall back 
    in can be very helpful.
    
    A project I am overseeing (not ebXML related) involves a complicated 
    database schema, and an XML API which is used to collect information for 
    insertion to the database.  The XML API is defined in WSDL referencing 
    our XML schema.  Our approach was to put the DBA in charge of updating 
    our various complexType declarations in the XML Schema.  So far, so 
    good -- your mileage may vary.
    
    Regards,
    
    Matt
    
    
    
    On Monday, February 18, 2002, at 06:13  PM, David Fischer wrote:
    
    > Dale,
    >
    > I like this proposal.  But, how can the schema be a normative part of 
    > the spec
    > yet change without a new version of the spec?  You seem to be arguing 
    > against
    > the schema taking precedence yet you then say it should?  If the schema 
    > is
    > non-normative, or normative in a separate document, then such fixes 
    > should be
    > easy.  I guess I don't understand.  I looks to me like your argument is 
    > somehow
    > both ways?
    >
    > My comment about caching locally was exactly to allow fixes.  Maybe I
    > misunderstood, but it seemed Doug was arguing for a central schema 
    > which took
    > precedence over everything.
    >
    > My main argument against the schema taking precedence is that we have 
    > not been
    > focusing on the schema in our discussions -- it has been somewhat of a 
    > side
    > issue without change tracking or control.  In fact, Chris' statement 
    > about the
    > schema becoming normative with the adoption of SOAP is incorrect.  In 
    > v1.0 after
    > SOAP became an integral part of TRP, the schema is specifically an 
    > EXAMPLE and
    > examples are non-normative (v1.0 section 4.4).  In v1.0, we made a 
    > point of
    > making sure the specification took precedence over the schema.
    >
    > Regards,
    >
    > David.
    >
    >