OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

IMO, it is tantamount to insanity to make world-wide eBusiness via ebXML
dependant upon a single schema in a single location.  If that location becomes
unavailable, does that mean all eBusiness throughout the world will stop?!?  It
seems far better to cache schema's locally and let implementations download the
*latest* schema from a central location.

Any time something becomes centrally located and important, it becomes
susceptible to attack by those wishing to do harm.  There is no way to stop a
Denial-Of-Service attack and a central location of our schema would present an
ideal target for such an event.

It seems far more reasonable to let implementations download, and utilize
locally, a schema which can be corrected and posted as needed.  This means there
is no longer any reason for the schema to *win* over the words.  We can simply
fix the schema any time we find a discrepancy.

I am also concerned since we have been making mass schema changes without group
discussion.  I am not even sure what changes have occurred since they have not
been tracked.  To make the schema win over the words means we have just thrown
all our discussions to the wind!



-----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]

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]

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
precedence, the Schema or the Text.



-----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:


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.



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
> the receiver MUST (at least SHOULD) validate a message against the
> Messaging schema.  If that's not supported by our documentation and
> 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
> because the schema requires its presence.  That code fails in ugly
> when those assumptions are violated by an non validating XML parser.)
> Due to the changes currently proposed resolving issue 73, I don't
> 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
> a schema.  First, the parser responsible for reading the instance must
> be configured to perform validation.  I don't recall whether or not
> requires such a parser configuration.  Second, the specific elements
> 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
> The schema found at [1] does not match our hacked version at [2] in
> 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
> [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
> the document in a few more ways than previously suggested.  In
> 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
> 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>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC