I was able to find a disussion of this in a prior thread (June, 2001). See
attached.
The relevant section is
> There is a statment in the spec which makes me a bit nervous. In
> section 4.2.1 it has a Note which says:
>
> "NOTE: As discussed in Missing Sub-components (§5.3), ˇQNameˇs in XML
> representations may fail to ˇresolveˇ, rendering components incomplete
> and unusable because of missing subcomponents. During schema
> construction, implementations are likely to retain ˇQNameˇ values for
> such references, in case subsequent processing provides a referent.
> ˇAbsentˇ target ˇnamespace nameˇs of such as-yet unresolved reference
> ˇQNameˇs in <include>d components **should** also be converted if clause
> 3.2 is satisfied."
Note that the "should" is what helped throw me off here; Henry says it
actually should be a "must". Or, rather, must be a "must". :-)
> -----Original Message-----
> From: Kohsuke KAWAGUCHI [mailto:kohsuke.kawaguchi@sun.com]
> Sent: Monday, October 15, 2001 12:49 PM
> To: ht@cogsci.ed.ac.uk; Jeff Lowery; xmlschema-dev@w3.org
> Subject: Re: Including schemas with no targetnamespace
>
>
>
> > Another way to think of it is that the schema is built, connections
> > made, etc., and _then_ <include>d. <include> is _not_ a textual
> > inclusion, it is specified and must be implemented at the component
> > level.
>
> This is interesting, as I think such a "repairing" is only possible by
> textual inclusion.
>
>
> In the table of section 3.3.2, the spec says:
>
> > otherwise (the <element> element information item has
> <complexType> or
> > <group> as an ancestor and the ref [attribute] is present), the
> > corresponding schema component is as follows:
>
> ...
>
> > {term}
> > The (top-level) element declaration *resolved* to by the *actual
> > value* of the ref [attribute].
>
> Since you are saying that inclusion is done at the component level,
>
> <xsd:element ref="color"/>
>
> has to be compiled into a Particle component, whose "term"
> property is
> ("","color") before the inclusion takes place.
>
>
> Now would you tell me when in the inclusion process this term property
> is modified to
> ("http://www.example.com/fruitbasket","color")? And where
> in the spec is that stated?
>
>
> regards,
> --
> Kohsuke KAWAGUCHI +1 650 786 0721
> Sun Microsystems kohsuke.kawaguchi@sun.com
>
Forwarded message 1
There is so much confusion about Chameleon components. I want to make
absolutely certain that I am not misunderstanding anything.
Let's take an example. Here's a no-namespace schema:
BookCatalogue.xsd
------------------------------------------------------
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<xsd:complexType name="CardCatalogueEntry">
<xsd:sequence>
<xsd:element name="Title"
type="xsd:string"/>
<xsd:element name="Author"
type="xsd:string"/>
<xsd:element name="Date"
type="xsd:string"/>
<xsd:element name="ISBN"
type="xsd:string"/>
<xsd:element name="Publisher"
type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
<xsd:element name="Book"
type="CardCatalogueEntry"/>
</xsd:schema>
------------------------------------------------------
Note that this schema has two components - a Book element and a
CardCatalogueEntry type - which are coupled, that is, Book references
CardCatalogueEntry:
Book --> CardCatalogueEntry
Below is a schema with a targetNamespace, which <include>s the above
no-namespace schema:
Library.xsd
------------------------------------------------------
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.library.org"
xmlns="http://www.library.org"
elementFormDefault="qualified">
<xsd:include schemaLocation="BookCatalogue.xsd"/>
<xsd:element name="Library">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="BookCatalogue">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="Book"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
------------------------------------------------------
Here's my understanding of what happens when this schema <include>s the
no-namespace schema:
[1] The two global components in the no-namespace schema are
namespace-coerced to the <include>ing schema's targetNamespace, i.e,
{Absent}Book --> {http://www.library.org}Book
{Absent}CardCatalogueEntry -->
{http://www.library.org}CardCatalogueEntry
[2] The reference in the declaration of Book changes from:
Book --> {Absent}CardCatalogueEntry
to
Book -->{http://www.library.org}CardCatalogueEntry
Consequently, as long as the <include>ing schema's default namespace is
the targetNamespace then Book's reference to CardCatalogueEntry will
resolve correctly. If the default namespace is XMLSchema then the
reference will fail (since there is no CardCatalogueEntry in the
XMLSchema namespace).
Is this correct?
There is a statment in the spec which makes me a bit nervous. In
section 4.2.1 it has a Note which says:
"NOTE: As discussed in Missing Sub-components (§5.3), ˇQNameˇs in XML
representations may fail to ˇresolveˇ, rendering components incomplete
and unusable because of missing subcomponents. During schema
construction, implementations are likely to retain ˇQNameˇ values for
such references, in case subsequent processing provides a referent.
ˇAbsentˇ target ˇnamespace nameˇs of such as-yet unresolved reference
ˇQNameˇs in <include>d components **should** also be converted if clause
3.2 is satisfied."
As I read it, the last sentence here is saying that if an unqualified
reference is made within the
Chameleon schema then the namespace URI used in resolving the reference
is the target namespace of the including schema.
What makes me nervous is that it says "should". It does not say
"must". Am I to assume then that some implementations may not resolve
unqualified references within the Chameleon schema to the target
namespace of the including schema? /Roger