W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > January to March 2008

[Bug 5276] targetNamespace defined on xs:element

From: <bugzilla@wiggum.w3.org>
Date: Fri, 15 Feb 2008 09:38:30 +0000
CC:
To: www-xml-schema-comments@w3.org
Message-Id: <E1JPx1a-0000fz-Aa@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5276





------- Comment #7 from mike@saxonica.com  2008-02-15 09:38 -------
As far as I can see, the problem this facility is trying to tackle is that when
someone defines a complex type whose content model includes local elements in
the target namespace of the containing schema, it is currently difficult or
impossible to define a restriction of that complex type in a schema document
whose target namespace differs from the original. For example if FPML defines a
set of messages, users of FPML should be able to define restrictions of those
messages without resorting to creation of schema documents whose target
namespace is the FPML namespace.

Personally, I don't see why this problem can't be solved by allowing a
locally-declared element to be in any namespace whatsoever, with no
restrictions. We currently give a choice of two: the target namespace of the
containing schema document, or the namespace-that-dares-not-speak-its-name. I
don't see any reason to restrict it that way. After all, we allow a content
model to have a wildcard that permits elements in any namespace: so in effect
the current rule is that if you want to allow elements in a "foreign" namespace
you can do so, but you can't constrain their local name or type.

We should just add a namespace="" attribute to <xs:element> (allowed when there
is a name attribute and the element is local). (I can't actually see any reason
to call it targetNamespace, what does "target" add?). The restrictions on this
appear to serve no useful purpose, and they prevent you doing some useful
things.

This proposal goes beyond what is needed to solve the immediate problem. That's
generally good: if a solution with fewer rules and restrictions works, then use
it.

Concerning comment #5, I think there would be some merit in saying that "target
namespace" is always a property of a schema document, and that
"##targetNamespace" is always a reference to this property. If we used
"namespace" rather than "targetNamespace" when defining the names of
locally-declared elements and attributes it will remove this source of
confusion. Unfortunately the element declaration schema component has a
property called {target namespace} and I know we are reluctant to change
property names. So this may be a non-starter.
Received on Friday, 15 February 2008 09:38:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 6 December 2009 18:13:13 GMT