Re: [dita] Use of standardized prefixes when incorporating foreign vocabularies

["W. Eliot Kimber" <ekimber@innodata-isogen.com>]

Eric Sirois wrote:
> While helping a user understand/integrate MathML DTD using the foreign
> element the example in the proposal it used the mml prefix while the DTD
> itself defines the prefix m.  Another example would be the use of namespace
> prefix xs and xsd for XML Schemas.  When using DTDs, it is quite possible
> that  two different organizations can create two perfectly legal
> specializations using two different prefixes.  The topics created based on
> the two specialization is no longer shareable.

I'm not sure why you say this: each topic must be initially validated 
and processed in its own document context and that document context must 
specify the correct namespace URI for the local prefixes.

Any processor that processes the two topics in the same process in order 
to produce a new instance reflecting the combining of those topics in 
some way and doesn't either rewrite the prefixes or locally declare the 
namespaces is simply not a namespace-aware process and therefore not a 
candidate for use in this case.

That is, once you start using namespaces for anything, all your tools 
need to be namespace aware. Expecting that prefixes will be consistent 
and invariant is simply not realistic.

In addition, this points up the fact that DTDs, as opposed to XSD 
schemas and similar namespace-aware constraint mechanisms, are really 
not viable options for handling namespaced data for the simple fact that 
the constraint specifications are not themselves namespace aware, 
meaning that you are dependent on the local prefixes. That is, DTDs 
cannot reflect the fact that <foo xmlns="bar"> and <foo xmlns="baz"> are 
two fundamentally different element types.

This is one reason that I don't see DTDs being useful *at all* in a 
general XML context and begin to question the wisdom of any standard, 
DITA included, providing DTDs except as a convenience or as a way of 
expressing requirements (without expecting the declarations to be used 
literally with documents). The problem with the DITA specification as 
currently defined is that it imposes constraints on the structure *of 
the DTDs*, which somewhat puts it in an untennable position.

I continue to assert that DITA should be making no normative 
requirements on how documents' constraint specifications are 
constructed--it should only be making requirements on the rules for 
document instances. Any DTD or schemas normatively defined by DITA 
should be meta schemas that define rules that instances must conform to 
but that are not necessarily the literal specifications of those rules 
that all instances are expected to use.

Cheers,

E.


-- 
W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(214) 954-5198

ekimber@innodata-isogen.com
www.innodata-isogen.com