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