Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Controlled Intermixing of Namespaced Element Types

From: Eliot Kimber <ekimber@---------------.--->
To: xml-schema-dev <xmlschema-dev@--.--->
Date: 3/22/2005 3:10:00 PM
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@i...
www.innodata-isogen.com


From ht@i... Wed Mar 23 09:14:22 2005
Received: from bart.w3.org ([128.


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent