W3C home > Mailing lists > Public > xmlschema-dev@w3.org > October 2004

Re: xs:include changing targetNamespace

From: Henry S. Thompson <ht@inf.ed.ac.uk>
Date: Tue, 05 Oct 2004 10:19:54 +0100
To: "Michael Kay" <mhk@mhk.me.uk>
Cc: <xmlschema-dev@w3.org>
Message-ID: <f5bacv1a5dx.fsf@erasmus.inf.ed.ac.uk>

"Michael Kay" <mhk@mhk.me.uk> writes:

> Questions about xs:include where the including schema document has a
> targetNamespace and the included document does not:
>
> In 4.2.1, Schema Representation Constraint: Inclusion Constraints and
> Semantics, rune 3.2.1, [Part 1, PER of 2004-03-18] there is apparently a
> typo: "whose code was qualified" should presumably be "whose form was
> qualified".

Yes.

> The implication is that the absent namespace should only be replaced by the
> target namespace in places where the target namespace would have been used.
> This would imply that <xs:element ref="A"/> (assuming there is no default
> namespace) is still to be interpreted as a reference to A in the
> absent-namespace, not a reference to A in the (new) target namespace

Need more information to clarify.  There are three possibilities:

 1) The <xs:element ref="A"/> and the declaration of A are in the
    <include>d schema document.  In that case, the reference has been
    resolved during the construction of "the ˇschema componentsˇ of
    I", and clause 3.2.1 will change the TNS of A, a top-level
    component, to the <includ>ing TNS.

 2) The <xs:element ref="A"/> is in the <include>d schema document,
    but there is no declaration for A therein.  In this case the
    paragraph below the constraint comes in to play:

    "ˇAbsentˇ target ˇnamespace nameˇs of such as-yet unresolved
     reference ˇQNameˇs in <include>d components must also be converted
     if clause 3.2 is satisfied."

 3) The <xs:element ref="A"/> is in the <includ>ing document.  No
    conversion is performed, and the reference stands or falls
    depending on whether there is an <xs:import/>.

> and that ##local in a wildcard still refers to the absent namespace,
> not the (new) target namespace. Correct? (And if so, is this
> actually usable?)

No, such wildcards are converted. 3.2.2 says

    "[replace ˇabsentˇ namespace with TNS in] [t]he {namespace
     constraint} of a wildcard, whether negated or not;"

> Is it true that the effect of including a schema document with no target
> namespace into a schema document with target namespace T is equivalent to
> modifying the included document so that it says targetNamespace="T" before
> processing it?

No.  That would leave all internal references undischarged.  It is
equivalent to constructing a schema for the included document, then
replacing ˇabsentˇ with the relevant TNS everywhere in the components
thereof called for in 3.2.1 and 3.2.2.

Note it is because of chameleon include that a list of schema
documents is _not_ sufficient to determine a schema -- you need a
labelled directed graph, with the labels being the TNS.

ht
-- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
Received on Tuesday, 5 October 2004 09:19:57 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:15:11 UTC