RE: Including schemas with no targetnamespace

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
> 

attached mail follows:

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