This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
[The problem] It's desirable to provide schema document syntax that eases complex type restriction. Currently the derived type has to repeat almost the entire base content model, which may be very inconvenient in some cases. 1. It's common that, especially when people are paying more and more attention to schema evolution, a wildcard in the base type needs to be replaced by some element declarations. This seemingly simple task also requires an entire copy of the unchanges portions of the base content model. 2. When the base content model has elements with anonymous types or identity constraints, it's not possible to repeat them, hence making it impossible to refine the base type, at least without extensive use of named groups. 3. When a complex type restricts a base type from different namespace, again it's impossible to repeat the base content model, because many of the elements have a {target namespace} that's different from the current schema document's target namespace. [Suggestion] 1. Make it possible to replace pieces of the base content model without repeating the rest. May need to use a path language like SCD to specify which pieces to replace. 2. Allow a targetNamespace attribute on local element/attribute declarations to be able to declare declaration in other namespaces.
Discussed at 2006-10-31 F2F meeting. Adopted a proposal that meets the second suggestion. Closing this bug. Bug 4222 is opened to track the first suggestion separately.
Adding Bassam Tabbara to the CC list, as his message sent to the schema comments list is for the same issue: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2007JanMar/0025 As comment #1 indicates, this request was resolved by allowing "targetNamespace" on local elements and attributes. The specific wording changes are available in the following (member-only) draft: http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b3836-1.200610.html As the originator of this issue, I'm happy with this resolution. So I'm closing this bug accordingly.