Re: Controlled Intermixing of Namespaced Element Types

Henry S. Thompson wrote:
> Same answer as yesterday :-)
> 
> Substution groups were specifically designed to reconstruct the use of
> parameter entities for content models as mechanisms for controlled
> extension.

OK. I'm not sure why Henry put the cell type into a separate schema, but
in any case I was able to create a simple working example following his
model, except in my case it is the cell element that gets substituted
(since having a lower-level content element just adds an unnecessary
level of containment [but see below]).

In Henry's example the tc:content element corresponds logically to what
would be a parameter entity in the equivalent DTD. The difference I
think is that the parameter entity doesn't require an additional layer
of element containment. This may be an unavoidable cost of a
markup-based, rather than syntatic, approach (although I imagine it
might have been possible to define away to have directly-replacable
content models rather than requiring element-level substitution, but I
wasn't involved in the initial design so this is inappropriate
Monday-morning quarterbacking).

But my solution should be functionally equivalent *if* processing is
based on the underlying type and not on the element type name, in which
case there is no ambiguity about the semantic of the substituted cell
element. If processing may be based only on the element type name then
the extra level of containment is required so that the cell element type
name is invariant (and thus generalized table processors will reliably
recognize the element as being a table cell). Hmmm.

I'm still trying to get my head around what the standard practice should
be with respect to the use of types and element type names. In
particular, should all specialization be done with types, with element
type names being essentially local, undependable aliases for the types?
I think this is the right thing to do in the abstract but it does
require more definitional effort (because element types that differ only
in element type name that could be declared as being of the same type
would require that a unique type be declared for each one). I also find
it frustrating that there is no way to directly relate types to types,
but that you have to go through elements. [More MMQBing]

I'm thinking mostly about generalized processors that want to be able to
examine the type heirarchy of an element to see if it is a type they
recognize, i.e., in this example a generic table renderer that expects
the base types of table elements to be types it recognizes. I need to
see what the XSLT processing implications are....

Cheers,

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 Thursday, 24 March 2005 15:24:32 UTC