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

[Dale Moberg <dmoberg@cyclonecommerce.com>]

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>