Re: [ebxml-msg] Issue 56: Specification / Schema conflict resolution

[Christopher Ferris <chris.ferris@sun.com>]

David,

With all due respect, the XML schema in v1.0 was normative.

Before the decision was made to go with SOAP 1.1 as the
underlying protocol, we did have a non-normative XML Schema
version of the normative DTD, but the adoption of SOAP
changed all of that and the XML schema for our ebXML
SOAP extension elements became, of necessity, normative
(and we had to drop the DTD because SOAP doesn't support
DTDs).

The schema needs to be normative IMO.

Cheers,

Chris

David Fischer wrote:

> Doug,
> 
> No, we don't have to ratify both the text and the schema.  The v1.0 group
> validated only the text with an EXAMPLE schema in an appendix.  I suggest, we
> should follow that path.  All we have to ratify is the text.
> 
> I am looking for, but have not yet found, an example of a standard in which code
> takes precedent over the words.  Is there such a thing?  All the ones I have
> looked at so far are specifically the reverse.
> 
> Perhaps we should pull the schema out of the spec and have it as a separate,
> non-normative document?
> 
> Regards,
> 
> David.
> 
> -----Original Message-----
> From: Doug Bunting [mailto:dougb62@yahoo.com]
> Sent: Sunday, February 17, 2002 1:32 AM
> To: dick@systrends.com; ebXML
> Subject: Re: [ebxml-msg] Issue 56: Specification / Schema conflict
> resolution
> 
> 
> Dick,
> 
> Sorry to return to an issue after it's a little cold.
> 
> I agree completely where the document and specification overlap they should
> agree.  However, the schema contains information not in the document and
> visa versa.  In addition, we're not going to be perfect.   Our comments on
> the Description element and the SequenceNumber datatype shouldn't be taken
> to mean we've found every place the two things don't match.
> 
> I don't agree the document should win simply because we discussed it more in
> our group.  As a group, we should be publishing a schema and a document
> which form a unified answer to the question of "how do I send an ebXML
> document?"  We must ratify both.  We must also understand how the schema
> will be used and recognise that use in our document.
> 
> While some XML parsers may cache copies of the schema, what we publish at
> the location described in the document is a normative part of our overall
> protocol description.  The interesting thing is how a receiving application
> could possibly override the behaviour of the XML parser to meet the terms of
> the document.  Since the SOAP processor and it's embedded XML parser (in a
> layered approach using a generic SOAP processor) or an XML parser alone
> (feeding information to a somehow mixed MSH and SOAP processor) will process
> the document before the code of an ebXML Messaging handler, the message
> should be validated against the schema before the MSH starts doing its work.
> Certainly, code could be written to send a message that won't validate
> against the schema but the receiver will have a hard time using code to get
> past the validation error.
> 
> I generally see the document as describing (referencing and explaining) the
> normative information in the schema for the areas the two things overlap.
> The layers in an MSH implementation sitting on top of an XML parser (and,
> likely, a SOAP processor) are what developers can directly control.  They
> have to take the schema as a given.  That's why it "wins" if there should
> ever be a conflict now or in the future.
> 
> thanx,
>     doug
> 
> ----- Original Message -----
> From: "Dick Brooks" <dick@systrends.com>
> To: "Doug Bunting" <dougb62@yahoo.com>; "ebXML"
> <ebxml-msg@lists.oasis-open.org>
> Sent: Tuesday, February 12, 2002 3:58 PM
> Subject: RE: [ebxml-msg] Issue 56: Specification / Schema conflict
> resolution
> 
> 
> Doug,
> 
> I believe the specifications, which contain the consensus agreements of the
> workgroup, should take precedence over the schema.
> 
> IMO, the schema should "implement" the spec without modification. If the
> schema is "wrong" an "errata" for the schema should be issued.
> 
> Dick Brooks
> Systrends, Inc
> 7855 South River Parkway, Suite 111
> Tempe, Arizona 85284
> Web: www.systrends.com <http://www.systrends.com>
> Phone:480.756.6777,Mobile:205-790-1542,eFax:240-352-0714
> 
> 
> -----Original Message-----
> From: Doug Bunting [mailto:dougb62@yahoo.com]
> Sent: Tuesday, February 12, 2002 5:38 PM
> To: ebXML
> Subject: [ebxml-msg] Issue 56: Specification / Schema conflict
> resolution
> 
> 
> We need to choose a "winner" when (as will inevitably happen) the words of
> the
> specification disagree with the separate schema instance.  My suggestions
> make
> clear choices rather than leaving things open.  Further, we need to choose a
> winner our programs can implement without conflicting with a normative
> deliverable from our group.  We provide a schema that arriving messages will
> be checked against before the application even hears about it.  Therefore,
> it
> will win and that must be reflected in our documentation.
> 
> 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>
>