Charles Fineman <cf**************@yahoo.com> 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