OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: Schema-Specification normative preference wasRE:[ebxml-msg]Issue73:http://schemas.xmlsoap.org/soap/envelopenamespace


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/



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC