[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
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC