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

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