headers
Michael Kay | 9 Oct 2006 18:03
Favicon
Gravatar

RE: Is schemaLocation just a hint in schema import?


> "NOTE: The above is carefully worded so that multiple 
> <import>ing of the same schema document will not constitute a 
> violation of clause 2 of Schema Properties Correct (§3.15.6), 
> but applications are allowed, indeed encouraged, to avoid 
> <import>ing the same schema document more than once to 
> forestall the necessity of establishing identity component by 
> component.
> Given that the schemaLocation [attribute] is only a hint, it 
> is open to applications to ignore all but the first <import> 
> for a given namespace, regardless of the ·actual value· of 
> schemaLocation, but such a strategy risks missing useful 
> information when new schemaLocations are offered."
> 
> 
> Can anybody tell me the motivation for this note in the schema spec?
> 

I've pointed out in comments on 1.1 that if the spec really were carefully
worded, then the (non-normative) note wouldn't be needed.

The spec, I think, is saying two things:

(a) if you do two imports from the same schemaLocation (whatever "same"
means) then you should be OK; the components should only be imported once.

(b) if you do two imports from different schemaLocations (whatever
"different" means) then it's pretty much undefined what happens: the system
may import both and report any conflicts (such as the same element
declaration appearing in both), or it may import both and detect that the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Xan Gregg | 9 Oct 2006 18:14
Favicon

Re: Is schemaLocation just a hint in schema import?


> Does it mean that you can't have 2 schemas defining different  
> elements for
> the same namespace and then import both from another schema?

Not reliably, anyway. For a given schema usage, there is one schema  
for a given namespace URI. A "schema document" is different from a  
"schema". From the XML Schema perspective, a schema is roughly a set  
of schema components all having the same namespace URI.

> Should everything for a given schema be defined in just one schema  
> file? If
> you have a big schema definition for different functional areas, it  
> might be
> useful to split the schema in several files so you don't need to  
> import
> elements that you won't be using.

There may be multiple schema documents used to create a schema;  
however, you can only reliably import a schema using a single  
location. Instead, you should build a grouping schema document that  
<xs:include>s the other schema documents that are in the same  
namespace and then import the schema using the location of the  
grouping schema document.

> Can anybody tell me the motivation for this note in the schema spec?

To allow maximum flexibility in schema processors. For instance, to  
allow a processor to keep known schemas in a cache, while ignoring  
the location hint altogether. However, this flexibility can lead to
(Continue reading)

Permalink | Reply | 2 comments |
headers
noah_mendelsohn | 10 Oct 2006 01:38
Picon
Favicon

Re: Is schemaLocation just a hint in schema import?


Let me give a slightly different spin on Xan's responses.

Xan Gregg writes:

> > [Leo Antoli writes]:
> > Does it mean that you can't have 2 schemas
> > defining different elements for the same
> > namespace and then import both from another
> > schema?
> 
> Not reliably, anyway. For a given schema usage,
> there is one schema for a given namespace URI. A
> "schema document" is different from a
> "schema". From the XML Schema perspective, a
> schema is roughly a set of schema components all
> having the same namespace URI.

Not quite how I see it.  A schema is a set of components to be used for a 
validation, and crucially it can intgrate multiple target namespaces. 
E.g., if a type and its basetype are in different target NS's, or if an 
element and its substitution group head are in different targetNS's, then 
it becomes clear why there is one schema integrating all the components, 
rather than a separate schema per namespace.  For example, I might have a 
schema document with the single declaration:

<schema targetNamespace="ns1uri" xmlns:ns2="ns2uri">
<simpleType name="derived">
  <restriction base="ns2:othertype>
    <maxInclusive value="10"/>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Antoli, Leo | 17 Oct 2006 16:11
Favicon

RE: reference to element, elementFormDefault unqualified


Hi,
Have you used or you know of some public schema which uses 
elementFormDefault="unqualified" ?

Are there good reasons to use it? Are there good reasons to avoid it?

Sorry because it's quite an open question but any thoughts about that will
be more than welcome.

Thanks.

Regards,
Leo Antoli

-----Original Message-----
From: Michael Kay [mailto:mike <at> saxonica.com] 
Sent: 13 April 2006 16:47
To: 'Oliver Kusche'; xmlschema-dev <at> w3.org
Subject: RE: reference to element, elementFormDefault unqualified

elementFormDefault="unqualified" means that a locally-declared element (one
declared with <element name="x"> as part of a complex type) will be in no
namespace. (I've always thought this was a weird thing to want to do.)
Elements declared at the top level of a schema are always in the target
namespace of that schema, regardless of the value of elementFormDefault in
either their own schema document or in a referencing schema document.

You might be able to achieve what you want using chameleon includes, but
that's another strange facility that I prefer to admire from a distance.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Paul Spencer | 24 Oct 2006 13:20
Picon

Schema 1.1 wishlist (was: [xml-dev] RE: Is schemaLocation just a hint in schema import?)


There is definitely confusion among tool vendors on imports and includes,
especially with regard to namespaces. These is my wish list for clearing up
some of it. It is based on extensive experience of creating and reviewing
schemas (and writing schema guidelines) for UK Government.

I see no reason why a namespace should not contain names created from
multiple schema documents. In fact, this is a very logical and modular way
of creating schemas. Currently, as has been pointed out, the behaviour is
undefined when a schema document xs:imports multiple other documents with
the same target namespace. Hence we have the messy work-around of
xs:including the required documents into another and then xs:importing that.

Another problem I come across is multiple levels of xs:including chameleon
schemas. The spec gets interpreted two ways. If schema document A (target
namespace nsA) xs:includes B (no target namespace) that itself xs:includes
document C (no target namespace), I would like it to be clear that all
global components exist in the namespace nsA. We discussed this here several
years ago. Some tools do not interpret it this way, instead leaving the
components of document C without a target namespace. This severely limits
the use of chameleon schemas (which some will regard as a good thing).

There are other problems of different interpretations by tool vendors that
relate to hierarchies of schemas. I am sure the spec could be clarified in
this area just by thinking in terms of more than two layers in a hierarchy.

Paul Spencer

> -----Original Message-----
> From: xmlschema-dev-request <at> w3.org
(Continue reading)

Permalink | Reply | 0 comments |

Gmane