- From: <bugzilla@wiggum.w3.org>
- Date: Fri, 15 Feb 2008 09:38:30 +0000
- To: www-xml-schema-comments@w3.org
- CC:
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 UTC