targetNamespace/import conflict

Discussion in 'XML' started by Charles Fineman, Jan 21, 2004.

  1. I've been asked to look over an integration toolkit that has a bunch
    of schemas to specify message format. There are a couple of strange
    things I noticed right off the bat and I wanted to get others'
    thoughts on it (disclaimer, obviously I'm no XML expert so forgive me if
    these are basic).

    --------Exhibit A: The start of a response message schema-----------


    <xsd:schema targetNamespace="http://www.QQQ.com"
    xmlns:QQQ="http://www.QQQ.com/datatypes"
    xmlns="http://www.QQQ.com"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    elementFormDefault="unqualified">

    <xsd:import namespace="http://www.QQQ.com/datatypes"
    schemaLocation="../general/datatypes.xsd"/>

    <xsd:import namespace="http://www.QQQ.com"
    schemaLocation="../general/datatypes.xsd"/>


    --------Exhibit B: The start of general/datatypes.xsd --------------

    <xsd:schema targetNamespace="http://www.QQQ.com/datatypes"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns="http://www.QQQ.com/datatypes"
    elementFormDefault="unqualified"
    attributeFormDefault="unqualified">

    --------------------------------------------------------------------

    #1) Exhibit A seems to be following poor form by using such a generic
    targetNamespace (the same one is used for all their top-level schema).
    The convention I've seen is that the targetNamespace should be the
    public URL of the document.

    #2) Exhibit A defines both the default and QQQ namespace to point to
    the same schema (namely, Exhibit B). I guess I don't have a problem
    with it technically (sans #3) but it does seem bizarre. Seems like a
    really bad idea in fact. Would you do this so you could normally refer
    to a name X without qualification unless there were some ambiguity with
    an X in the current document (and so you could refer to it as QQQ:X)?

    #3) The namespace used in the 2nd import of Exhibit A does not match the
    targetNamespace of Exhibit B. Why would someone do this?

    #4) Please confirm/dispute my interpretation of the elementForDefault
    and the attributeFormDefault: all these say is that I do not have to qualify
    elements in the document but they are still implicitly part of the
    default namespace for that document (and hence would be subject to the
    appropriate validations).

    If this is all just bad form, so be it (and I may have a chance to
    get it fixed) but if there are plausible reasons for why one would
    do things this way I sure would like to hear about them.

    Thanks,

    Charlie Fineman
     
    Charles Fineman, Jan 21, 2004
    #1
    1. Advertising

  2. Charles Fineman <cfineman-no&> writes:

    > --------Exhibit A: The start of a response message schema-----------
    >
    > <xsd:schema targetNamespace="http://www.QQQ.com"
    > xmlns:QQQ="http://www.QQQ.com/datatypes"
    > xmlns="http://www.QQQ.com"
    > xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    > elementFormDefault="unqualified">
    >
    > <xsd:import namespace="http://www.QQQ.com/datatypes"
    > schemaLocation="../general/datatypes.xsd"/>
    >
    > <xsd:import namespace="http://www.QQQ.com"
    > schemaLocation="../general/datatypes.xsd"/>
    >
    >
    > --------Exhibit B: The start of general/datatypes.xsd --------------
    >
    > <xsd:schema targetNamespace="http://www.QQQ.com/datatypes"
    > xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    > xmlns="http://www.QQQ.com/datatypes"
    > elementFormDefault="unqualified"
    > attributeFormDefault="unqualified">
    >
    > --------------------------------------------------------------------
    >
    > #1) Exhibit A seems to be following poor form by using such a generic
    > targetNamespace (the same one is used for all their top-level schema).
    > The convention I've seen is that the targetNamespace should be the
    > public URL of the document.


    Odd, perhaps, but it doesn't seem likely to make anything harder, now
    or later. On the question of whether a namespace name should be
    dereferenceable, large numbers of electrons have been spilt; suffice
    to say that both sides of the question can be argued, and are.

    > #2) Exhibit A defines both the default and QQQ namespace to point to
    > the same schema (namely, Exhibit B).


    Well, not as you have shown it. Exhibit A and Exhibit B each define
    their target namespace as their default namespace. Exhibit A binds
    the prefix 'QQQ' to the URL "http://www.QQQ.com/datatypes", not to the
    default namespace (which is "http://www.QQQ.com").

    And (pedantry alert) Exhibit B is, I assume, a document available via
    some URI. A namespace is an abstraction named by a URI, and should
    not be confused with a document.

    > #3) The namespace used in the 2nd import of Exhibit A does not match
    > the targetNamespace of Exhibit B. Why would someone do this?


    Good question.

    Perhaps they want to test the conformance of the schema processor: as
    far as I can tell, the second import statement violates constraint
    src-import.1.1 (" If the namespace [attribute] is present [on the
    import element], then its actual value must not match the actual value
    of the enclosing <schema>'s targetNamespace [attribute]").

    As it happens, Xerces J agrees with me: its error message is

    [Error] a.xsd:11:38: src-import.1.1: The namespace attribute
    'http://www.QQQ.com' of an <import> element information item
    must not be the same as the targetNamespace of the schema it
    exists in.

    To my surprise, XSV doesn't seem to catch this problem and
    accepts the schema documents.

    > #4) Please confirm/dispute my interpretation of the
    > elementForDefault and the attributeFormDefault: all these say is
    > that I do not have to qualify elements in the document but they are
    > still implicitly part of the default namespace for that document
    > (and hence would be subject to the appropriate validations).


    Well, I think you're close but I'm not sure I understand exactly what
    you mean.

    If the elementFormDefault and attributeFormDefault attributes are both
    set to "unqualified", it means that local elements and local
    attributes are defined without any namespace affiliation. They will
    be referred to in a document instance by unqualified names
    (i.e. unprefixed names in an environment without a default namespace),
    and occurrences of them in the document instance in the relevant
    contexts will be validated against the relevant declarations or
    definitions in the schema -- so far, I think this is what you mean by
    "I do not have to qualify elements in the document" and by being
    "subject to the appropriate validations".

    But they are not implicitly, explicitly, or in any other way "in", or
    "part of", the target namespace of the schema document. (Or, to be
    painfully precise, such a conclusion is not licensed by either the
    namespaces Rec or the XML Schema spec.) Their only link to the target
    namespace is that they are declared as local to a type defined in the
    target namespace.

    I hope this helps.

    -C. M. Sperberg-McQueen
     
    C. M. Sperberg-McQueen, Jan 27, 2004
    #2
    1. Advertising

  3. Thanks for the response... only just now noticed it :)

    C. M. Sperberg-McQueen wrote:

    > Charles Fineman <cfineman-no&> writes:
    >
    >
    >>--------Exhibit A: The start of a response message schema-----------
    >>
    >> <xsd:schema targetNamespace="http://www.QQQ.com"
    >> xmlns:QQQ="http://www.QQQ.com/datatypes"
    >> xmlns="http://www.QQQ.com"
    >> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    >> elementFormDefault="unqualified">
    >>
    >> <xsd:import namespace="http://www.QQQ.com/datatypes"
    >> schemaLocation="../general/datatypes.xsd"/>
    >>
    >> <xsd:import namespace="http://www.QQQ.com"
    >> schemaLocation="../general/datatypes.xsd"/>
    >>
    >>
    >>--------Exhibit B: The start of general/datatypes.xsd --------------
    >>
    >><xsd:schema targetNamespace="http://www.QQQ.com/datatypes"
    >> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    >> xmlns="http://www.QQQ.com/datatypes"
    >> elementFormDefault="unqualified"
    >> attributeFormDefault="unqualified">
    >>
    >>--------------------------------------------------------------------
    >>


    >>#2) Exhibit A defines both the default and QQQ namespace to point to
    >>the same schema (namely, Exhibit B).

    >
    >
    > Well, not as you have shown it. Exhibit A and Exhibit B each define
    > their target namespace as their default namespace. Exhibit A binds
    > the prefix 'QQQ' to the URL "http://www.QQQ.com/datatypes", not to the
    > default namespace (which is "http://www.QQQ.com").
    >
    > And (pedantry alert) Exhibit B is, I assume, a document available via
    > some URI. A namespace is an abstraction named by a URI, and should
    > not be confused with a document.
    >


    Ah but this was the source of my confusion. In this case, they specify
    that the document in exhibit B as the definition of both the default and
    QQQ namespace. I just don't see the value in doing this.


    >
    >>#4) Please confirm/dispute my interpretation of the
    >>elementForDefault and the attributeFormDefault: all these say is
    >>that I do not have to qualify elements in the document but they are
    >>still implicitly part of the default namespace for that document
    >>(and hence would be subject to the appropriate validations).

    >
    >
    > Well, I think you're close but I'm not sure I understand exactly what
    > you mean.
    >
    > If the elementFormDefault and attributeFormDefault attributes are both
    > set to "unqualified", it means that local elements and local
    > attributes are defined without any namespace affiliation. They will
    > be referred to in a document instance by unqualified names
    > (i.e. unprefixed names in an environment without a default namespace),
    > and occurrences of them in the document instance in the relevant
    > contexts will be validated against the relevant declarations or
    > definitions in the schema -- so far, I think this is what you mean by
    > "I do not have to qualify elements in the document" and by being
    > "subject to the appropriate validations".
    >
    > But they are not implicitly, explicitly, or in any other way "in", or
    > "part of", the target namespace of the schema document. (Or, to be
    > painfully precise, such a conclusion is not licensed by either the
    > namespaces Rec or the XML Schema spec.) Their only link to the target
    > namespace is that they are declared as local to a type defined in the
    > target namespace.
    >


    Thanks... the distinction is clear and makes sense. I have questions
    about ambiguity rolling around in my head though... what happens in
    complex types when sub-elements come from different name spaces. For
    example, can we ever run into problems with things like:

    <a:A>
    <b:B>
    <c:C>
    <value> ... </value>
    </c:C>
    </b:B>
    </a:A>

    If value is declared in multiple namespaces?

    Thanks again for the response.
     
    Charles Fineman, Feb 9, 2004
    #3
    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. kevin bailey

    targetnamespace - what is it?!?!

    kevin bailey, Jun 24, 2003, in forum: XML
    Replies:
    1
    Views:
    17,465
    kevin bailey
    Jun 25, 2003
  2. CB
    Replies:
    0
    Views:
    3,329
  3. C. M. Sperberg-McQueen

    Re: transforming to an XML Schema - targetNamespace

    C. M. Sperberg-McQueen, Jul 29, 2003, in forum: XML
    Replies:
    0
    Views:
    538
    C. M. Sperberg-McQueen
    Jul 29, 2003
  4. charles cashion

    css conflict (or html conflict)

    charles cashion, Feb 18, 2009, in forum: HTML
    Replies:
    2
    Views:
    797
    charles cashion
    Feb 18, 2009
  5. Bill
    Replies:
    0
    Views:
    206
Loading...

Share This Page