Re: Import and change target namespace is desirable

At 2000-12-11 13:33, Bob Schloss wrote:
>Proposal for a New XML Schema Feature: Import and Change Target Namespace
>
>The current import mechanism in W3C XML Schema does not allow the target
>namespace of the elements (i.e. types etc) being imported to be modified;
>they are brought into the importing schema, but their target namespace
>remains unchanged.  Of course, it is possible to do this at the moment by
>copying and pasting the elements you would like to import into your schema,
>but this obviously has its limitations. A second current method is to use
>include with an included file that does not specify a targetNamespace.

A third is to use the 'redefine' construct, which allows the second
version of a schema to change some declarations 'in place' as it were,
and have the effects of those changed declarations propagated throughout
the schema.

All of your immediate use cases seem to me to be met by 'redefine'. Do
you disagree?  Or was its use not clear?

>For example, in the schema for SOAP 1.1 encoding [1], which bases its type
>system on that of XML Schema, the simple types being defined are
>essentially 'copy and pasted' from the Datatypes Schema.

It seems to me that this shows a need for some way of 'naturalizing'
names so that they become part of the local namespace.  (Here: to
allow SOAP to pull declarations for types into the SOAP namespace,
while still making visible to processing software that the names in
question have the same meaning they do in XML Schema.)  Cases like this
persuade me that many people want not what namespaces give us but
something like what architectural forms would give us.  So far, I
seem to be in a minority in this view.

>However, the main use of such a feature might be when evolving a schema.  A
>common scenario might be that an organisation wants to evolve a version 1
>schema by adding some types/elements to it, and then placing the 'new'
>schema in a new target namespace.  An import and change target namespace
>feature would avoid having to copy and paste all of the version 1 schema
>into the version 2 schema.

This sounds like a very straightforward use case for 'redefine'.  In the
remainder of this note, I describe briefly where the WG came out on the
design questions you mention, when we added 'redefine' to the spec.

>The things that would need to be decided about such a feature are:
>
>- Can any new target namespace be specified, or just that of the current
>schema?
>   The cases we have seen would be satisfied if the new target namespace
>would be the TNS of the importing schema.

The schema document being included-and-redefined, and the one doing the
include-and-redefining, must (as things now stand) have the same target
namespace.

>- Can an import statement be selective about the elements it imports?
>(This would really be needed in the SOAP 1.1 example, and of course raises
>the question of how to specify a selection.  For schema v1.0 it would
>probably be best to only be able to import the entire schema.)

I agree that in the long run this would be good.  (Explicit control of
import and export of names seems like a good tool for modularization.)
In the current draft, neither redefine, nor include, nor import, can be
made selective.  (We did have the ability to import/include some but not
all components, in an earlier draft.  The comments showed that no one
saw the need or utility, and everyone was acutely aware of the
complexity.)

>- Can an import statement somehow change the local name, as well as the
>target namespace, of an element?  (Once again, more something to consider
>for Schema language version 2.)  (See below for info on how this is
>currently done in a long-winded syntax).

Not with 'redefine' in the CR draft.

-CMSMcQ

Received on Wednesday, 27 December 2000 14:01:40 UTC