W3C home > Mailing lists > Public > xmlschema-dev@w3.org > March 2005

Controlled Intermixing of Namespaced Element Types

From: Eliot Kimber <ekimber@innodata-isogen.com>
Date: Tue, 22 Mar 2005 21:10:05 -0600
Message-ID: <4240DE0D.4030607@innodata-isogen.com>
To: xml-schema-dev <xmlschema-dev@w3.org>

My reading of the spec and experimentation says that there is no way to 
import types in a specific namespace (different from the namespace of 
the importing schema) and also control, in the importing schema, what 
element types are allowed at defined extension points within the 
imported schema. I want to confirm that I haven't missed some subtle use 
of redefine or substitution groups or something.

The use case I'm trying work out is typified by the standard table model 
use case (e.g., OASIS tables), except instead of having all elements in 
the same namespace, having the table-specific structures come from a 
module in its own namespace (i.e., a namespace for tables, owned and 
controlled by the definer of the table model) but providing "extension 
points" where arbitrary elements can be inserted, i.e., the contents of 
the "entry" or "td" elements.

The key here is that the table elements are not in the namespace of 
their containing elements but in their own, invariant namespace (which 
would enable, for example, unambiguous recognition of the markup as 
being the standard table markup).

I can of course define the content of the "entry" element to be "any" 
with a namespace of "##other". This indicates clearly that, as far as 
the table is concerned, you can put anything there you want, as long as 
it's not another table.

But what I can't seem to do is say in the importing schema that I want 
to further restrict the element types allowed in that context.

This is trying to do, in a cleanly namespaced way, what, for example, 
the current table model DTDs do with parameter entities meant to be 
locally redefined by including declaration sets. There doesn't appear to 
be any facility analogous that mechanism that doesn't require either the 
use of a single namespace or no namespace.

Have I missed something?

Thanks,

Eliot
-- 
W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(512) 372-8155

ekimber@innodata-isogen.com
www.innodata-isogen.com
Received on Wednesday, 23 March 2005 03:08:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 January 2011 00:14:49 GMT