If the group consensus is to give the schema precedence over the spec then I
suggest schema creation follow the same consensus process used to create the
spec. I don't believe this was the case in the past.
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: David Fischer [mailto:david@drummondgroup.com]
Sent: Monday, February 18, 2002 10:17 AM
To: Dale Moberg; Christopher Ferris; Doug Bunting
Cc: ebXML Messaging
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!
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>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>