Duane:
In message-header-2_0.xsd, we include the following import clauses:
<import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation="http://www.oasis-open.org/committees/ebxml-msg/schema/xmldsi
g-core-schema.xsd" />
<import namespace="http://www.w3.org/1999/xlink"
schemaLocation="http://www.oasis-open.org/committees/ebxml-msg/schema/xlink.
xsd" />
<import namespace="http://schemas.xmlsoap.org/soap/envelope/"
schemaLocation="http://www.oasis-open.org/committees/ebxml-msg/schema/envelo
pe.xsd" />
<import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/03/xml.xsd" />
These import clauses are necessary because attributes and elements defined
in these foreign namespaces are actually referenced within the message
header schema (e.g., soap:mustUnderstand, xlink:href, ds:Signautre,
xml:lang, etc). I don't think the message header schema would be valid
without the import clauses.
The import construct is used in the schema definition, not in an instance
document. I am a little confused when you wrote:
> > 1. In an instance document, the attribute xsi:schemaLocation provides
hints
> > from the author to a processor regarding the location of schema
documents.
> > The author warrants that these schema documents are relevant to checking
the
> > validity of the document content, on a namespace by namespace basis. For
> > example, we can indicate the location of the Report schema to a
processor of
> > the Quarterly Report:
> <SNIP>/.....
>
> My interpretation of the above: This refers to importing definitions in
> order to perform a validating parse on an "instance document" - as the
> example states. If someone wishes to check the validity of a namespace
> qualified element to see if its' content matches (ie - datatyping
> constaints or content model), then they may have to resolve the
> schemalocation.
>
> What I am asking is "Is the requirement importing definitions OR is it
> to avoid naming conflicts?"
-Arvola
----- Original Message -----
From: "Duane Nickull" <duane@xmlglobal.com>
To: "Arvola Chan" <arvola@tibco.com>
Cc: "Dale Moberg" <dmoberg@cyclonecommerce.com>; "David Fischer"
<david@drummondgroup.com>; "Christopher Ferris" <chris.ferris@sun.com>;
"Doug Bunting" <dougb62@yahoo.com>; "ebXML Messaging"
<ebxml-msg@lists.oasis-open.org>
Sent: Monday, February 18, 2002 4:59 PM
Subject: Re: Schema-Specification normative preference wasRE:
[ebxml-msg]Issue73:http://schemas.xmlsoap.org/soap/envelopenamespace
> Comments inline:
>
> Arvola Chan wrote:
> >
> > Duane:
> >
> > The reason why the ebxml-msg TC has to define its own namespace is
because
> > the ebXML message header elements are defined as extensions to the SOAP
> > Header and SOAP body elements. SOAP requires extension elements to be
> > namespace qualified.
> >>>>>>>
>
> Arvola:
>
> Yes - I am very aware of namespaces themselves. My question revolved
> around a comment that someone made to this thread complaining that they
> could not import the definitions from the namespace schemaLocation
> target. I wondered why it would ever be a requirement to import the
> actual definitions (the specification says you must be able to do so via
> the schemalocation attribute as you quote below.). If it is a
> requirement, then I personally was curious of the driver for that
> requirement.
>
> It seems like it may not be a formal requirement and that perhaps we are
> simply using the namespace values to avoid conflicts (since you cite the
> SOAP example as the driver). If this is true, then there is no
> problem.
>
> >
> > The schemaLocation attributes in the schema and in instance documents
only
> > serve as hints. Schema processors are not required to use these hints.
The
> > application that invokes a schema processor can direct the latter not to
> > dereference the value specified for the schemaLocation attribute and
instead
> > use some cached version of the schema.
> >>>>>
>
> Local caching still requires you resolve it at least once.
>
> > The following is an excerpt from http://www.w3.org/TR/xmlschema-0/
> >
> > "
> > 5.6 schemaLocation
> > XML Schema uses the schemaLocation and xsi:schemaLocation attributes in
> > three circumstances.
> >
> > 1. In an instance document, the attribute xsi:schemaLocation provides
hints
> > from the author to a processor regarding the location of schema
documents.
> > The author warrants that these schema documents are relevant to checking
the
> > validity of the document content, on a namespace by namespace basis. For
> > example, we can indicate the location of the Report schema to a
processor of
> > the Quarterly Report:
> <SNIP>/.....
>
> My interpretation of the above: This refers to importing definitions in
> order to perform a validating parse on an "instance document" - as the
> example states. If someone wishes to check the validity of a namespace
> qualified element to see if its' content matches (ie - datatyping
> constaints or content model), then they may have to resolve the
> schemalocation.
>
> What I am asking is "Is the requirement importing definitions OR is it
> to avoid naming conflicts?"
>
> If anyone knows the answer, can they please state the answer and if it
> is definition importing as a strict requirement, please state why.
>
> Thanks
>
> Duane Nickull
> --
> CTO, XML Global Technologies
> ****************************
> Transformation - http://www.xmlglobal.com/prod/foundation/
> ebXML Central - http://www.xmlglobal.com/prod/central/