David and Arvola,
I'm confused. In our discussions yesterday, we generally agreed
2.3.2 should stay but include MAY instead of MUST. The sentiments
was primarily around the xsi:schemaLocation attribute doing no harm and
avoiding unnecessary changes to the document. Why has this come back
again?
Chris has also commented on the three points Arvola originally raised.
Were his suggestions incorporated in the changing document and schema?
I'm also concerned we're attempting to vote upon a moving target.
If we don't have something stable to designate a TC specification and (potentially
later) submit to OASIS, let's get things to that state before the vote.
In the meantime, let's push back on Karl and get a (slight) extension to
the submission deadline.
thanx,
doug
Arvola Chan wrote:
David: My
personal opinion is that the entire section 2.3.2 xsi:schemaLocation
attribute is obsolete and no longer necessary now that the "http://schemas.xmlsoap.org/soap/envelope/"
namespace and the "http://www.oasis-open.org/committees/ebxml-msg/msg-header-2_0.xsd"
namespace can be directly resolvable (see strategies 3 and 5 in the following
excerpt from http://www.w3.org/TR/xmlschema-1/). 4.3.2
How schema definitions are located on the Web
Schema
Representation Constraint: Schema Document Location Strategy
Given a namespace
name (or none) and (optionally) a URI reference from xsi:schemaLocation
or xsi:noNamespaceSchemaLocation, schema-aware processors may
implement any combination of the following strategies, in any order:
1 Do nothing, for
instance because a schema containing components for the given namespace
name is already known to be available, or because it is known in advance
that no efforts to locate schema documents will be successful (for example
in embedded systems);
2 Based on the
location URI, identify an existing schema document, either as a resource
which is an XML document or a <schema>
element information item, in some local schema repository;
3 Based on the
namespace name, identify an existing schema document, either as a resource
which is an XML document or a <schema>
element information item, in some local schema repository;
4 Attempt to resolve
the location URI, to locate a resource on the web which is or contains
or references a <schema>
element;
5 Attempt to resolve
the namespace name to locate such a resource.
Whenever possible configuration and/or
invocation options for selecting and/or ordering the implemented strategies
should be provided.
If we adopt this change, then all of
the examples should have the schema locations for the above two namespaces
removed. In addition, the introductory material in Appendix A also needs
tweaking. If we choose not to make the suggested
changes, we should at least update the cached schemas we have on the ebxml-msg
TC web site for the SOAP envelope and for xmldsig-core-schema. Regards,-Arvola
-----Original
Message-----
From: David Fischer <>
To: Arvola Chan <>
Date: Tuesday, February 19,
2002 7:15 PM
Subject: RE: schema in [ebxml-msg]
v2.0 rev b, etc.
Did
I get this right? It required changes throughout the document.What
did we decide about xsi:schemaLocation? Do we need it in all the
examples?David.
-----Original
Message-----
From: Arvola Chan [mailto:]
Sent: Tuesday, February 19,
2002 7:14 PM
To: David Fischer; Ian. C.
Jones (E-mail); ebXML Msg
Subject: Re: schema in [ebxml-msg]
v2.0 rev b, etc.
David: I am not sure if we really
want to leave the following unchanged in the schema: 1.
<import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="http://www.oasis-open.org/committees/ebxml-msg/schema/xmldsig-core-schema.xsd"/>
2.
<import namespace="http://www.w3.org/1999/xlink" schemaLocation="http://www.oasis-open.org/committees/ebxml-msg/schema/xlink.xsd"/>
3.
<import namespace="http://schemas.xmlsoap.org/soap/envelope/" schemaLocation="http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd"/>
With
respect to #1 above, please seehttp://lists.oasis-open.org/archives/ebxml-msg/200202/msg00154.html
I think we should be referencing the
official version of xmldsig-core-schema.xsd instead of the snapshot we
have been maintaining at our web site.
With respect to #2 above, I am not able
to find any official xlink.xsd on the W3C web site. We will have to continue
to use our own version located at our web site unless someone can identify
the location for an official version of xlink.xsd.
With respect to #3 above, please see
http://lists.oasis-open.org/archives/ebxml-msg/200202/msg00056.html
We may want to use "http://schemas.xmlsoap.org/soap/envelope/"
as the schema location since that is the official SOAP 1.1 schema. The
only potential issue is that the former includes Annotation and you have
previously mentioned that some parsers used by members of the interop team
cannot deal with Annotation.
I also notice two minor problems in
the References section:
1. The correct URL for BPSS should be
http://www.ebxml.org/specs/ebBPSS.pdf
2. Xlink has been a W3C Recommendation
since June 27, 2001. See http://www.w3.org/TR/xlink/
-Arvola
-----Original
Message-----
From: David Fischer <>
To: Ian. C. Jones (E-mail)
<>
Cc: ebXML Msg <>
Date: Tuesday, February 19,
2002 1:02 PM
Subject: [ebxml-msg] v2.0 rev
b
Ian, Here
is what we have at the moment. I have included both an MSWord document
and a PDF. The PDF has change control off and the MSWord has it on. I
did not accept the changes from Rev A so both Rev A and Rev B changes show.
In my copy, Rev A changes are in Blue and Rev B changes are in Red.
In MSWord, if you put your cursor over the change, it will say "David V
Fischer" on the Rev A changes and "David Fischer" on the Rev B changes.
It would probably be appropriate, if anyone wants to make quick comments
in the next day or so, to use the line numbers in the PDF.I
don't think either of these documents is appropriate to vote on.
Arvola said he would review the schema (Appendix A) and let me know what
further changes I need to make to align with his copy.I
don't know where we are on the change control document. I have not
looked at anything since Rev A but I have made a couple of changes based
upon the conference calls and the eMail list (mostly related to Errata
locations and OPTIONAL treatment and Chris' item 229). The easiest
way to see these is to look for changes marked in red (at least it is red
on my PC).One
final thought. If we vote on this and it passes, I would like to
suggest we change the version of the last document to v1.9 and this one
to v2.0.Regards,David
FischerDrummond
GroupebXML-MS
Editor.
