David:
The
import clauses in the schema need to stay. Whenever we make use of elements
and/or attributes from a foreign namespace within the schema, we have to do the
corresponding import. Within an instance document, i.e., in an ebXML message, we
don't need to have xsi:schemaLocation attributes for the SOAP and ebMS
namespaces because those namespaces directly resolve to the corresponding
schemas. We have never included a schema location attribute for the xlink
namespace in our examples, I believe. That is not necessary because the schema
location for that namespace is already specified in
msg-header-2_0.xsd.
I
don't believe it is required to include a schema location in the import
construct, when the namespace directly resolves to the correct schema. However,
if some schema processors (like XML Spy) have problems when the schema location
is omitted, then I agree that we can provide a schema location for the imported
SOAP namespace that is identical to the namespace.
I suggest replacing the following
text
It was necessary to craft a
schema for the XLINK [XLINK] attribute vocabulary to conform to the W3C
XML Schema Recommendation [XMLSchema].
Xlink
- http://www.oasis-open.org/committees/ebxml-msg/schema/xlink.xsd
with
It was necessary to craft a schema for the
XLINK [XLINK] attribute vocabulary to conform to the W3C XML Schema
Recommendation [XMLSchema]. This schema is referenced from the ebXML SOAP
extension elements schema and is available from the following
URL:
http://www.oasis-open.org/committees/ebxml-msg/schema/xlink.xsd
Off hand, I think all of the schemaLocation attributes
in the message instance examples can just go away. If you send me a preliminary
draft of your revision, I can take a look at the examples and give you some
quick feedback. I notice that in the Version 2.0 rev B draft, the syntax for
some of the xsi:schemaLocation attributes are not correct because there are
three values included within the quoted string. The correct syntax should be any
number of tuples each comprised of a namespace and a schema location.
Regards,
-Arvola
-----Original
Message-----
From: David Fischer
[mailto:]
Sent: Thursday, February 21, 2002
6:10 AM
To: Arvola Chan;
Subject: RE: schema in [ebxml-msg] v2.0
rev b, etc.
I agree, but I'm still confused. Since we import the
...oasis-open...xlink.xsd into our schema, is the xsi:schemaLocation for xlink
required on our examples?
The text in Appendix A, above the schema, has been almost entirely
removed. The only thing remaining says:
It was necessary to craft
a schema for the XLINK [XLINK] attribute vocabulary to conform to the
W3C XML Schema Recommendation [XMLSchema].
Xlink
- http://www.oasis-open.org/committees/ebxml-msg/schema/xlink.xsd
Regards,
David.
-----Original Message-----
From: Arvola Chan
[mailto:]
Sent: Wednesday, February 20, 2002 10:49
AM
To: David Fischer;
Subject: Re: schema in [ebxml-msg]
v2.0 rev b, etc.
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 see
http://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 Fischer
Drummond Group
ebXML-MS
Editor.
