Re: [ebxml-msg] envelope.xsd

[Doug Bunting <dougb62@yahoo.com>]

Since my name has appeared a few times in this thread attached to opinions I didn't
intend to express, thought I'd chime in.

First, I intended to suggest exactly what Chris put into words.  We agreed during a
recent teleconference not to remove all of 2.3.2 because we couldn't ignore the real
possibility developers would include the schemaLocation attribute and point to various
XSD documents for each and every namespace we define or that must appear in an ebXML
Message (I think that's just our schema and SOAP's).  As we've been discussing for
quite some time now, we also should not be even strongly recommending a non-normative
XSD instance when discussing the SOAP namespace.

I can also understand a potential problem for implementations if we completely remove
our current envelope.xsd file.  The removal of one or two lines when sending ebXML
Message instances must be balanced against those instance documents not making use of
the normative SOAP schema.  We have been working to define ebXML Messaging as a valid
extension set for SOAP, not a protocol that uses "something like" SOAP.

Going a bit further, we can't "just" fill our envelope.xsd file with the contents from
schemas.xmlsoap.org.  That schema instance has not been submitted to our group nor
have we (or can we) changed the copyrights to say "OASIS" in that document.

I would suggest
1) making the changes to 2.3.2 Chris has suggested.  I might go one step further and
change "strongly RECOMMENDED" to "MAY" on line 625 because the SOAP schema location
matches the namespace identifier.  The "Failure to include the schemaLocation
attribute could prevent XML schema validation of received messages." sentence on lines
627-8 is also strong for this reason.

2) cleaning up the http://www.oasis-open.org/committees/ebxml-msg/schema/ directory to
remove any XSD instances no longer correct or necessary.  At the moment, this would
mean removing envelope.xsd and xml_lang.xsd.  I'm not going to be the only person who
lists this directory and others may be confused by the inclusion of these files.

3) correct our schema instance's <import /> elements to reference the right location
for the SOAP envelope namespace:

  <import namespace="http://schemas.xmlsoap.org/soap/envelope/"
schemaLocation="http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd" />

becomes

  <import namespace="http://schemas.xmlsoap.org/soap/envelope/"
schemaLocation="http://schemas.xmlsoap.org/soap/envelope/" />

4) dredging up our discussion of the XML dsig namespace to remind us all if anyone
found a XML Schema Recommendation - compliant version of that XSD instance.  In other
words, can the <import /> below point to some normative location?  If so, making
similar changes (as in 2 and 3 above) to use this normative XSD instance.  Sorry, I
don't remember the result of this part of that long thread.  I only recall that our
xlink.xsd file is as good as it gets.

<import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation="http://www.oasis-open.org/committees/ebxml-msg/schema/xmldsig-core-schema.xsd"
/>

thanx,
    doug

Christopher Ferris wrote:

> I think that this has nothing to do with any implementations
> or implementers. If they want to continue to specify
> xsi:schemaLocation for the SOAP envelope schema, that is a perfectly
> valid thing to do. The point is that our specification should
> not (IMO) call out a requirement that implementations use
> a non-normative version of the SOAP envelope schema document.
>
> Cheers,
>
> Chris
>
> David Fischer wrote:
>
> > At the risk of repeating myself...  We should leave the spec alone at this
> > point.  I would have preferred to remove all mention of
> > http://www.oasis-open.org/.../envelope.xsd but it was too late.
> >
> > I think Arvola's plan of replacing the kludged schema with a copy of the W3C one
> > is good, but it is not up to me -- ask the implementors (bTrade, Cyclone,
> > Sybase, Sterling, Tibco, Fujitsu, XML Global, ...).  We need to be ultra
> > sensitive to the implementors now.  They are the ones who will get this spec to
> > market and determine whether it becomes pervasive.
> >
> > Regards,
> >
> > David.
> >
> > -----Original Message-----
> > From: Arvola Chan [mailto:arvola@tibco.com]
> > Sent: Tuesday, March 05, 2002 5:18 PM
> > To: Christopher Ferris
> > Cc: David Fischer; Ian. C. Jones (E-mail); ebXML Msg
> > Subject: RE: [ebxml-msg] envelope.xsd
> >
> >
> > Chris:
> >
> > Your line numbers are a bit off. Which version of the spec are you referring
> > to? Here is the relevant portion in the 2_0c spec:
> >
> > 2.3.2 xsi:schemaLocation attribute 618
> > The SOAP namespace: 619
> > http://schemas.xmlsoap.org/soap/envelope/ 620
> > resolves to a W3C XML Schema specification. The ebXML OASIS ebXML Messaging
> > TC has provided 621
> > an equivalent version of the SOAP schema conforming to the W3C
> > Recommendation version of the XML 622
> > Schema specification [XMLSchema]. 623
> > http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd 624
> > All ebXML MSH implementations are strongly RECOMMENDED to include the
> > XMLSchema-instance 625
> > namespace qualified schemaLocation attribute in the SOAP Envelope element to
> > indicate to validating 626
> > parsers a location of the schema document that should be used to validate
> > the document. Failure to 627
> > include the schemaLocation attribute could prevent XML schema validation of
> > received messages. 628
> > For example: 629
> > <SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" 630
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 631
> > xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/ 632
> > http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd"> 633
> > In addition, ebXML SOAP Header and Body extension element content may be
> > similarly qualified so as 634
> > to identify the location where validating parsers can find the schema
> > document containing the ebXML 635
> > namespace qualified SOAP extension element definitions. The ebXML SOAP
> > extension element schema 636
> > has been defined using the W3C Recommendation version of the XML Schema
> > specification 637
> > [XMLSchema] (see Appendix A). The XMLSchema-instance namespace qualified
> > schemaLocation 638
> > attribute should include a mapping of the ebXML SOAP Envelope extensions
> > namespace to its schema 639
> > document in the same element that declares the ebXML SOAP Envelope
> > extensions namespace. 640
> >
> > Your suggested changes do not seem directly applicable to the 2_0c spec.
> > Also, it may still be puzzling to uninitiated readers why we have introduced
> > our own snapshot of envelope.xsd without the deleted information. If we make
> > changes to the spec at this point, I would have preferred that we do it
> > properly by specifying http://schemas.xmlsoap.org/soap/envelope/ as the
> > schema location. If we want to leave the spec as is, then I recommend
> > replacing the contents of
> > http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd.
> >
> > Regards,
> > -Arvola
> >
> > -----Original Message-----
> > From: Christopher Ferris [mailto:chris.ferris@sun.com]
> > Sent: Tuesday, March 05, 2002 1:43 PM
> > To: Christopher Ferris
> > Cc: Arvola Chan; David Fischer; Ian. C. Jones (E-mail); ebXML Msg
> > Subject: Re: [ebxml-msg] envelope.xsd
> >
> >
> > oops, I meant to include the email in which I made
> > a proposal to address the schemaLocation section.
> >
> > Since it isn't archived, here is the relevant fragment
> > from the email I sent to David, Ian, Arvola and Doug:
> >
> > -------------------------------------------------------------------
> > *** w/r/t section 2.3.2, I think that its removal in whole is uncalled
> > for. I would propose
> > the following alternative approach:
> >
> > 1 - delete lines 620-639
> > 2 - modify line 640 as follows:
> >
> > In addition, ebXML SOAP Header and Body extension element content must
> > may be similarly qualified so as to identify the location where
> > validating parsers can find the schema document containing the ebXML
> > namespace qualified SOAP extension element definitions.
> >
> > 3 - modify example at line 651 as follows:
> >
> >      <SOAP:Envelope
> > xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"
> >      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >       xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/
> >
> > http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd" >
> >
> > -------------------------------------------------------------------
> > Cheers,
> >
> > Chris
> >
> > Christopher Ferris wrote:
> >
> >
> >>Arvola,
> >>
> >>And I countered with a proposal that I think addressed the
> >>issue without actually removing the schemaLocation section[1].
> >>
> >>The point is (from my perspective) that we don't want to
> >>preclude use of schemaLocation (for any purpose) but that
> >>we don't necessarily want to encourage its use for the
> >>SOAP envelope.xsd since we really don't own this.
> >>
> >>We previously had an issue w/r/t the version of XSD that
> >>was used to create the schema document at the namespace
> >>URI, but we no longer have an issue so why are we continuing
> >>to recommend this practice.
> >>
> >>I would suggest that if anything, we say that the schemaLocation
> >>is:
> >>
> >>xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/
> >>http://schemas.xmlsoap.org/soap/envelope/"
> >>
> >>If we replace what is at:
> >>
> >>http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd
> >>
> >>
> >>with what is at:
> >>
> >>http://schemas.xmlsoap.org/soap/envelope/
> >>
> >>I'm okay with that too, but we still don't want to advertise this
> >>in the spec IMO.
> >>
> >>Cheers,
> >>
> >>Chris
> >>
> >>Arvola Chan wrote:
> >>
> >>
> >>>Chris:
> >>>
> >>>Both Doug and members of the interop team objected to the removal of
> >>>section
> >>>2.3.2 on the xsi:schemaLocation attribute.
> >>>
> >>>Here is an excerpt from the 2_0c spec:
> >>>
> >>>2.3.2 xsi:schemaLocation attribute
> >>>The SOAP namespace: http://schemas.xmlsoap.org/soap/envelope/ resolves
> >>>to a
> >>>W3C XML  schema specification. The ebXML OASIS ebXML Messaging TC has
> >>>provided an equivalent version of the SOAP schema conforming to the W3C
> >>>Recommendation version of the XML Schema specification [XMLSchema].
> >>>
> >>>http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd
> >>>
> >>>All ebXML MSH implementations are strongly RECOMMENDED to include the
> >>>XMLSchema-instance
> >>>namespace qualified schemaLocation attribute in the SOAP Envelope
> >>>element to
> >>>indicate to validating parsers a location of the schema document that
> >>>should
> >>>be used to validate the document. Failure to include the schemaLocation
> >>>attribute could prevent XML schema validation of received messages. For
> >>>example:
> >>>
> >>><SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"
> >>>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >>>xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/
> >>>http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd">
> >>>
> >>>-Arvola
> >>>
> >>>-----Original Message-----
> >>>From: Christopher Ferris [mailto:chris.ferris@sun.com]
> >>>Sent: Tuesday, March 05, 2002 12:35 PM
> >>>To: Arvola Chan
> >>>Cc: David Fischer; Ian. C. Jones (E-mail); ebXML Msg
> >>>Subject: Re: [ebxml-msg] envelope.xsd
> >>>
> >>>
> >>>I thought that we had agreed that we should be referencing
> >>>http://schemas.xmlsoap.org/soap/envelope/ directly?
> >>>
> >>>Chris
> >>>
> >>>Arvola Chan wrote:
> >>>
> >>>
> >>>
> >>>>David:
> >>>>
> >>>>Since the spec still recommends the use of
> >>>>
> >>>>http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd
> >>>>
> >>>>as the schema location for the SOAP Envelope, do we want to replace the
> >>>>content of
> >>>>
> >>>>http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd
> >>>>
> >>>>with the content of
> >>>>
> >>>>http://schemas.xmlsoap.org/soap/envelope/ so that we are using the
> >>>>
> >>>>
> >>>official
> >>>
> >>>
> >>>>SOAP 1.1 schema rather than our own crafted version?
> >>>>
> >>>>-Arvola
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>----------------------------------------------------------------
> >>>>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>
> >
> >
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>