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

[Matthew MacKenzie <matt@xmlglobal.com>]

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.
>
> -----Original Message-----
> From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
> Sent: Monday, February 18, 2002 9:37 AM
> To: David Fischer; Christopher Ferris; Doug Bunting
> Cc: ebXML Messaging
> Subject: Schema-Specification normative preference wasRE: [ebxml-msg]
> Issue73:http://schemas.xmlsoap.org/soap/envelopenamespace
>
>
>> 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.
>
> -----Original Message-----
> From: David Fischer [mailto:david@drummondgroup.com]
> Sent: Monday, February 18, 2002 8:01 AM
> To: Christopher Ferris; Doug Bunting
> Cc: ebXML Messaging
> Subject: RE: [ebxml-msg]
> Issue73:http://schemas.xmlsoap.org/soap/envelopenamespace
>
>
> Do we have a call tomorrow?  I can't find any coordinates.
>
> If so, I would like to suggest we discuss this topic first -- which
> takes
> precedence, the Schema or the Text.
>
> Regards,
>
> David.
>
> -----Original Message-----
> From: Christopher Ferris [mailto:chris.ferris@sun.com]
> Sent: Monday, February 18, 2002 6:39 AM
> To: Doug Bunting
> Cc: ebXML Messaging
> Subject: Re: [ebxml-msg] Issue73:
> http://schemas.xmlsoap.org/soap/envelopenamespace
>
>
> Doug,
>
> I agree with all your points on the importance of
> validating the received messages before processing... However,
> SOAP does not *require* either DTD processing or XML Schema
> validation. This does not preclude XML Schema validation
> to assess the validity of the received message. I thnk that
> at best we can *strongly recommend* that the practice
> of validating the received message(s) against the XML
> Schema instance to assure receipt of a both well-formed
> and valid message before turning it over to further
> processing by the MSH. I don't think that we can
> necessarily *require* that this be done.
>
> w/r/t the process=lax v strict issue, that raises an
> interesting point that probably should be addressed
> by the XML Protocol WG regarding the SOAP schema.
>
> Cheers,
>
> Chris
>
> Doug Bunting wrote:
>
>> While writing my previous email (on issue 56) to Dick, I recognised an
>> assumption not supported in the document (I think).  I've been
> assuming
>> the receiver MUST (at least SHOULD) validate a message against the
> ebXML
>> Messaging schema.  If that's not supported by our documentation and
> the
>> SOAP envelope schema, we're in a whole world of security hurt.  (Just
>> for example, code is often written assuming something is in the DOM
> tree
>> because the schema requires its presence.  That code fails in ugly
> ways
>> when those assumptions are violated by an non validating XML parser.)
>> Due to the changes currently proposed resolving issue 73, I don't
> think
>> we have the assurance of XML validation if we ever did in the past.
>>
>>
>>
>> Two things determine whether or not an XML instance is validated
> against
>> a schema.  First, the parser responsible for reading the instance must
>> be configured to perform validation.  I don't recall whether or not
> SOAP
>> requires such a parser configuration.  Second, the specific elements
> of
>> interest must be declared within a processContents="strict" block.
>> Without strict interpretation of the block, a validating
>> parser MAY or MUST (depending on the precise declaration) skip the
> block.
>>
>>
>>
>> The schema found at [1] does not match our hacked version at [2] in
> one
>> important way: The one we threw together for our own use required
>> validation of the SOAP extension elements found in the Envelope and
>> Header.  [2] instead uses processContents="lax".  This means a
>> validating parser MAY skip the contents of the Header and Envelope
> elements.
>>
>>
>>
>> [1] http://schemas.xmlsoap.org/soap/envelopenamespace
>>
>> [2] http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd
>>
>>
>>
>> To make the suggested change to our msg-header.xsd file, we must
> change
>> the document in a few more ways than previously suggested.  In
> addition
>> to removing mention of our specific schema location for the SOAP
>> namespace, we must STRONGLY RECOMMEND the XML parser be configured to
>> interpret processContents="lax" as processContents="strict".   (I'd
>> prefer MUST to avoid long sentences describing requirements in this
>> area for any level of security assurance.)  If the SOAP specification
>> doesn't do this for us already, we should also require the XML parser
> to
>> validate received documents.
>>
>>
>>
>> thanx,
>>
>>     doug
>>
>>
>>
>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
--
Matthew MacKenzie
XML Global R&D
PGP Key available upon request.