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

[David Fischer <david@drummondgroup.com>]

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>