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

[Arvola Chan <arvola@tibco.com>]

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.

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.

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:

Using schemaLocation in the Quarterly Report, 4Q99html.xml
<purchaseReport
  xmlns="http://www.example.com/Report"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.example.com/Report
  http://www.example.com/Report.xsd"
  period="P3M" periodEnding="1999-12-31">

 <!-- etc. -->

</purchaseReport>

The schemaLocation attribute contains pairs of values: The first member of
each pair is the namespace for which the second member is the hint
describing where to find to an appropriate schema document. The presence of
these hints does not require the processor to obtain or use the cited schema
documents, and the processor is free to use other schemas obtained by any
suitable means, or to use no schema at all.

A schema is not required to have a namespace (see Section 3.4) and so there
is a noNamespaceSchemaLocation attribute which is used to provide hints for
the locations of schema documents that do not have target namespaces.

2. In a schema, the include element has a required schemaLocation attribute,
and it contains a URI reference which must identify a schema document. The
effect is to compose a final effective schema by merging the declarations
and definitions of the including and the included schemas. For example, in
Section 4, the type definitions of Address, USAddress, UKAddress, USState
(along with their attribute and local element declarations) from address.xsd
were added to the element declarations of purchaseOrder and comment, and the
type definitions of PurchaseOrderType, Items and SKU (along with their
attribute and local element declarations) from ipo.xsd to create a single
schema.

3. Also in a schema, the import element has optional namespace and
schemaLocation attributes. If present, the schemaLocation attribute is
understood in a way which parallels the interpretation of xsi:schemaLocation
in (1). Specifically, it provides a hint from the author to a processor
regarding the location of a schema document that the author warrants
supplies the required components for the namespace identified by the
namespace attribute. To import components that are not in any target
namespace, the import element is used without a namespace attribute (and
with or without a schemaLocation attribute). References to components
imported in this manner are unqualified.

Note that the schemaLocation is only a hint and some processors and
applications will have reasons to not use it. For example, an HTML editor
may have a built-in HTML schema.
"

-Arvola

----- Original Message -----
From: "Duane Nickull" <duane@xmlglobal.com>
To: "Dale Moberg" <dmoberg@cyclonecommerce.com>
Cc: "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:17 PM
Subject: Re: Schema-Specification normative preference wasRE:
[ebxml-msg]Issue73:http://schemas.xmlsoap.org/soap/envelopenamespace


>
>
> Dale Moberg wrote:
> >
> > I do not understand where David's implication
> > was drawn from. Certainly having a schemaLocation
> > for a schema does not necessarily mean that there
> > are no local caches. There are also nowadays some high
> > availability, fault tolerant, redundant, failover, load balancing
> > systems.
> >>>>>
> While that is possible,  it also depends on what you are counting on the
> schemalocation for.  If all trading partners who start using ebXML MUST
> download the schema definitions from that location, then the entire
> implementation phase is dependent on one point. This is clearly
> unacceptable.
>
> I suspect that simply having a namespace to avoid conflict of element
> and attroibute names is sufficient but I may be wrong.  My apologies if
> I have missed that part of the discussion.
>
> I would advocate that the designers of the specification who are telling
> us they are relying on resolving that schemaLocation attribute shoudl
> analyze exactly what functionality they need from the schemaLocation and
> see if it can;t be accomplished without creating this one focal point.
> The original author of the complaint hinted that they are having this
> problem.
>
> > This means that though there is one URL,
> > there need not be, in any pejorative sense, "a single
> > point of failure". A system backup is also possible.
> > DNS IP pools for the host, parallel live systems
> > running in sealed tunnels in Colorado, etc.
> >>>>>
> True - DNS uses a primary and secondairy nameserver however,  my
> question is "Does this need to be resolved in the first place".  I don;t
> know the answer.  I am merely posing the question.
>
> > What does any of this have to do with updating
> > a schema as a work-around for an interop. problem
> > arising from a discrepancy between normative words in a
> > specification and the normative schema of that
> > specification.
> >>>>>>>
> I have not the slightest idea here....
>
> Duane Nickull
>
> --
> CTO, XML Global Technologies
> ****************************
> Transformation - http://www.xmlglobal.com/prod/foundation/
> ebXML Central - http://www.xmlglobal.com/prod/central/
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>