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

[David Fischer <david@drummondgroup.com>]

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>