Import and change target namespace is desirable

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.

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.

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.

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.

- 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.)

- 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).

and so on... clearly this could be made very powerful, although this would
not be advisable at this point (post-CR of version 1.0) in the Schema
languages evolution.

Example syntax:

<import namespace="..." newtargetnamespace="..."/>

Concerns:
If the organizations maintaining the two schema files, and the two
namespaces, are not coordinating any minor changes that will occur to the
imported schema over time, a problem might arise for the importing schema
users.  So good practice would suggest that this facility only be used when
the two schemas are managed by the same organization, or there are
guaranteed to be no changes in the future to the imported schema.

-  -  -  -

A  extension of this proposal, which we are not requesting at this time,
follows:

Does it make sense to go farther, and provide an explicit syntax for
changing Target namespace and NCNAME as succinctly as possible?

A related issue is when you derive a type from another schema, but the only
change you want to make is to change the target namespace, and possibly the
local name, but no other facets.  This can be done at the moment, for
example:

<simpleType name="href">
  <restriction base="uriReference"/>
</simpleType>

(copied from the first example in the 'XLink Markup Name Control' W3C note.
[2])

But this is a verbose/limited way of doing this, especially if you want to
subtype a large number of types like this.  (But it does provide you with
control over each and every definition to be added to your TNS). (Our
proposal above would only support "mass" importing of type definitions.)

Clearly there are a number of questions regarding changing the target
namespace of elements from another schema, which have to be considered, and
could be deferred past the issue of Schema language version 1.0 .

regards,

--
David Bacigalupo (University of Warwick and IBM T. J. Watson Research
Center)
Bob Schloss (IBM T. J. Watson Research Center)


[1] http://schemas.xmlsoap.org/soap/encoding
[2] http://www.w3.org/TR/xlink-naming/#datatypes

Received on Monday, 11 December 2000 15:34:40 UTC