[XML Schema] Including a schema document with absent target namespace to a schema with specified tar

Discussion in 'XML' started by Stanimir Stamenkov, Apr 22, 2005.

  1. I'm trying to find out if it is permissible to include a schema
    document with absent target namespace to a schema with specified
    target namespace, and if it is, what are the rules to resolve the
    target namespace of the components from the included schema document.

    I'm confused because of the rules I read in the XML Schema spec
    <http://www.w3.org/TR/xmlschema-1/#element-element>:

    > If the <element> element information item has <schema> as its parent, the
    > corresponding schema component is as follows:
    > ...
    > {target namespace} The ·actual value· of the targetNamespace [attribute]
    > of the parent <schema> element information item, or ·absent· if there is none.
    > ...
    > otherwise if the <element> element information item has <complexType> or
    > <group> as an ancestor...
    > ...
    > {target namespace} If form is present and its ·actual value· is qualified,
    > or if form is absent and the ·actual value· of elementFormDefault on the
    > <schema> ancestor is qualified, then the ·actual value· of the
    > targetNamespace [attribute] of the parent <schema> element information item,
    > or ·absent· if there is none, otherwise ·absent·.


    and I've tried using the Xerces2 XSModel implementation with the
    following example:

    -----"primary-example.xsd"

    <?xml version="1.0" ?>
    <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
    targetNamespace="urn:x-example:test"
    xmlns:primary="urn:x-example:test">
    <xs:include schemaLocation="secondary-nonamespace.xsd" />
    <xs:element name="doc-root">
    <xs:complexType>
    <xs:sequence>
    <xs:element name="dummy" />
    <xs:element ref="primary:test-elem" />
    </xs:sequence>
    </xs:complexType>
    </xs:element>
    </xs:schema>

    -----"secondary-nonamespace.xsd"

    <?xml version="1.0" ?>
    <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
    elementFormDefault="qualified">
    <xs:element name="test-elem">
    <xs:complexType>
    <xs:sequence>
    <xs:element name="foo" />
    <xs:element name="bar" />
    </xs:sequence>
    </xs:complexType>
    </xs:element>
    </xs:schema>

    -----

    The result is the element components in the included schema are
    effectively put in the namespace of the including schema, although
    strictly following the rules I've quoted above it shouldn't be
    possible, I think.

    I guess I'm missing something - could someone point me out?

    --
    Stanimir
     
    Stanimir Stamenkov, Apr 22, 2005
    #1
    1. Advertising

  2. /Stanimir Stamenkov/:

    > I'm trying to find out if it is permissible to include a schema
    > document with absent target namespace to a schema with specified
    > target namespace, and if it is, what are the rules to resolve the
    > target namespace of the components from the included schema document.

    ....
    > I guess I'm missing something - could someone point me out?


    O.k. I've found it <http://www.w3.org/TR/xmlschema-1/#src-include>, clause 3.2.

    Feeling a bit silly now, but anyway. :)

    --
    Stanimir
     
    Stanimir Stamenkov, Apr 22, 2005
    #2
    1. Advertising

  3. (Stanimir Stamenkov) writes:

    > I'm trying to find out if it is permissible to include a schema
    > document with absent target namespace to a schema with specified
    > target namespace, and if it is, what are the rules to resolve the
    > target namespace of the components from the included schema
    > document.


    If a schema document gives no target namespace, the normal
    rules for processing that document will produce components
    without any target namespace, just as you say the relevant
    parts of the spec lead you to believe. In other words, your
    reading of the part of the spec you quote is quite right.

    When such a schema document is INCLUDED, however, special
    processing takes place, as described in section 4.2.1 of the
    specification [1]: The top level components without
    namespaces are treated as orphans, and given a new home in
    the namespace of the including document. (This doesn't
    strictly speaking contradict the material you quoted,
    because it's described not as a change to the mapping from
    XML source to schema components, but as an operation
    performed on the schema components derived from the
    included schema document.)

    [1] http://www.w3.org/TR/xmlschema-1/#compound-schema

    Components described in a schema document without a target
    namespace can thus take on the target namespace of any
    including schema document; the phenomenon is known for
    obvious reasons as 'chameleon include'.

    If that's not what you want -- if you just want those
    components, as is, without taking on the coloration of
    their surroundings -- then you want to be using import,
    not include. An import element in a schema document says
    two things: (1) "I'll be referring to components in
    another namespace, to wit: ...", and (2) (optionally)
    "Some components in that other namespace are over
    there; follow the schemaLocation info."

    xsd:import imports foreign namespaces; xsd:include includes
    new components for the current schema document's target
    namespace (and imposes the current target namespace on them
    if they don't have one of their own -- if they do have one,
    and it's different, then an include should raise an error).

    So if by 'include' you mean 'use the xsd:include mechanism',
    the answer is no, you cannot do what you describe in XML
    Schema 1.0. If by 'include' you just mean 'acquire the
    components', then the answer is 'yes, you can, by using
    the xsd:import mechanism rather than xsd:include'.

    If what you want is not so much a particular behavior as
    just to understand what's going on, then you may want to
    look at the current working draft of XML Schema 1.1 [2], in
    which part (not all, and not enough) of the treatment of
    schema composition has been revised to try to make it
    clearer. (No change of functionality, just the start of an
    attempt to lay it out more clearly.)

    [2] http://www.w3.org/TR/xmlschema11-1/

    I hope this helps.

    -C. M. Sperberg-McQueen
    World Wide Web Consortium
     
    C. M. Sperberg-McQueen, Apr 22, 2005
    #3
  4. /C. M. Sperberg-McQueen/:

    > If a schema document gives no target namespace, the normal
    > rules for processing that document will produce components
    > without any target namespace, just as you say the relevant
    > parts of the spec lead you to believe. In other words, your
    > reading of the part of the spec you quote is quite right.
    >
    > When such a schema document is INCLUDED, however, special
    > processing takes place, as described in section 4.2.1 of the
    > specification [1]: ...
    >
    > [1] http://www.w3.org/TR/xmlschema-1/#compound-schema


    Thank you for pointing it out. I've found it just after I've posted
    initially. It is that I use the spec more as a reference when I'm in
    doubt and sometimes I can't find what I'm looking for easily.

    > [2] http://www.w3.org/TR/xmlschema11-1/


    I've took a glance but haven't found much difference... may be I
    should look more closely, again. :)

    --
    Stanimir
     
    Stanimir Stamenkov, Apr 25, 2005
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Tony Prichard
    Replies:
    0
    Views:
    754
    Tony Prichard
    Dec 12, 2003
  2. Mads Orbesen Troest
    Replies:
    2
    Views:
    817
    Mads Orbesen Troest
    Apr 20, 2004
  3. Replies:
    1
    Views:
    525
    George Bina
    Jul 20, 2006
  4. Claudio Grondi
    Replies:
    4
    Views:
    572
    Claudio Grondi
    Aug 20, 2005
  5. Replies:
    2
    Views:
    435
    Michael Hoffman
    Apr 24, 2007
Loading...

Share This Page