Re:Re:[ebxml-msg]Issue73:http://schemas.xmlsoap.org/soap/envelopenamespace

[Rahul Srivastava <Rahul.Srivastava@Sun.COM>]

Thanks Arvola for the comments.

-Rahul.

> From: Arvola Chan <arvola@tibco.com>
> 
> Rahul:
> 
> Thanks for your feedback. My comments are inline.
> 
> -Arvola
> 
> -----Original Message-----
> From: Rahul Srivastava <Rahul.Srivastava@Sun.COM>
> To: ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org>
> Date: Tuesday, February 12, 2002 10:51 PM
> Subject:
> Re:[ebxml-msg]Issue73:http://schemas.xmlsoap.org/soap/envelopenamespace
> 
> 
> >Hi,
> >
> >After going through the messaging schemas at:
> >http://www.oasis-open.org/committees/ebxml-msg/schema/ I would like to make
> a
> >few comments, in the continuity of Issue73 thread.
> >
> >1. The way these schemas are written are not consistent.
> >        a) msg-header-2_0.xsd, envelope.xsd, xmldsig-core-schema.xsd have
> the
> >XMLSchema namespace (http://www.w3.org/2001/XMLSchema) as the default
> namespace,
> >whereas, xlink.xsd and xml_lang.xsd have the XMLSchema namespace prefixed.
> >                +It would be better if a single convention is followed when
> >writing the schemas. Either use prefixes or don't. The broad picture should
> be
> >uniform and consistent.
> 
> <arvola>
> The ebxml-msg TC is responsible for creating and maintaining
> msg-header-2_0.xsd; whereas envelope.xsd, xmldsig-core-schema.xsd and
> xlink.xsd have been developed by other groups. Because some parsers have
> trouble dealing with namespace URIs that do not directly resolve to their
> corresponding schemas, we have maintained explicit copies of envelope.xsd,
> xmldsig-core-schema.xsd and xlink.xsd to allow for the use of the
> xsi:schemaLocation construct to specify the schemas that are to be imported
> into their corresponding namespaces.
> 
> We previously maintained our own copy of xml_lang.xsd to allow for the use
> of the xml:lang attribute. Recently, we determined that we can instead make
> use of "http://www.w3.org/2001/03/xml.xsd" and we have opted to refer to the
> latter instead.
> 
> We have also discovered that the "http://schemas.xmlsoap.org/soap/envelope/"
> namespace URI has recently been updated to resolve to a SOAP 1.1 schema
> based on the W3C Recommendation version of XML Schema. Therefore, it is
> likely that we will make direct use of that, rather than maintaining our own
> envelope.xsd snapshot.
> 
> The point I am trying to make is that we don't have any control over these
> other schemas. We simply import them to allow for their reuse.
> </arvola>
> 
> >
> >        b) msg-header-2_0.xsd, xlink.xsd, xml_lang.xsd have
> elementFormDefault
> >and attributeFormDefault attributes specified and set to qualified,
> whereas,
> >envelope.xsd does not specify these attributes which defaults to
> unqualified and
> >xmldsig-core-schema.xsd specifies only elementFormDefault as qualified.
> >                +Here also inconsistency lies in the use of xxFormDefault
> >attributes. Somewhere it is used and somewhere it is not. Some have set it
> to
> >qualified and some have set it to unqualified. Setting attributeFormDefault
> to
> >qualified is not a good practice. If set, all the attributes in the
> instance
> >document must be prefixed. This looks like much of pain for the community
> and
> >will clutter the instance document with too many prefixes.
> 
> <arvola>
> Global attributes within a schema are always defined in the target namespace
> and have to be qualified. Unlike elements which can be implicitly qualified
> through the use of a default namespace, there is no equivalent default
> namespace mechanism that is applicable to attributes. To simplify the
> construction of an ebXML message instance, we have chosen to require that
> attributes always be qualified, to avoid the need for exact knowledge of
> whether an attribute defined in the ebMS namespace has to be qualified or
> not qualified.
> </arvola>
> >
> >2. There is very less use of annotation tags in these schemas.
> >        It would be nice and helpful to many if annotation tags are used to
> >describe the element tags e.g. TimeToLive, Action, etc.. This will improve
> the
> >readability of schema and make it more expressive. It would not be
> completely
> >wrong to say annotations are not at all used in these schemas.
> 
> <arvola>
> We have avoided the use of the annotation construct because some
> participants of the UCC sponsored ebMS interoperability study are using
> parsers that cannot deal with annotations. I agree that the use of
> annotations can improve readability of the schema.
> </arvola>
> 
> >
> >3. The namespace for msg-header-2_0.xsd,
> >'http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd'
> ends
> >in '.xsd'. This may confuse the community in namespace and schemalocation.
> I
> >vote against this.
> 
> <arvola>
> We have made a conscious decision to make the namespace identical to the
> schema location, because some parsers have difficulty locating schemas
> automatically unless the namespace URI resolves to the corresponding schema.
> We could have incurred more maintenance overhead on the OASIS ebxml-msg web
> site to ensure that a namespace URI without the .xsd extension resolves to
> the appropriate schema definition, but we chose to follow the precedence of
> the OASIS Security Services TC of including the '.xsd' in the namespace URI
> to simplify maintenance.
> </arvola>
> 
> >
> >I am still looking in these schemas. :-)
> >
> >Cheers,
> >Rahul.
> >
> >
> >----------------------------------------------------------------
> >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>


Sun Microsystems, Inc.