Re: [dita] Proposal for DITA namespaces

[Erik Hennum <ehennum@us.ibm.com>]

Esteemed DITA Committee:

I'd like, Eliot, to try to build on the good and difficult issues
raised in your and Mary's note.

I see the rationale for matching content objects with content handlers
based on the type and agree that the XML best practice is to use
namespaces to identify types.

Most XML vocabularies introduce a single type and thus require only
a single namespace.  DITA differs in that specializers introduce new
types and thus require new namespaces.

Using the same namespace both for core DITA and for specializations
would be analgous to using the same SGML public identifier for a core
DTD and for other DTDs that add new elements to the core DTD.  Neither
the namespace nor the public identifier would be reliable for
matching the correct content handler with the content.

The challenge, then, is to find a way to add namespaces without
breaking DITA's pluggable modularity.  The specializer has to be
able to derive a new type from an existing type -- each in its own
namespace -- by defining the design and processing deltas on the
base type.

To make matters more interesting, the specializer has to be
able to work in the design idiom of the schema language, whether
DTD (mainly entities) or XML Schema (mainly type extensions and
substitution groups).  We aren't converting a monolithic DTD or
Schema but, instead, supporting pluggable modularity in the
schema language of choice.

For the DITA design pattern in Schema, we could probably manage
the type system in an application layer on top of the schema
definition -- after all, that's how DITA is implemented on DTDs -- but
there are clear benefits to declaring the type in the syntax.  Instead
of writing custom applications for all type-sensitive operations,
common tools can be used.

For instance, once XSLT processors support type operators, DITA
fallback processing can be implemented using type expressions
instead of the current string comparisons on the class attribute.
The result will be gains for code simplicity and (probably)
performance.  Similarly, GUI design tools that understand type
inheritance can be used to define new specializations instead of
using a text editor and a lot of angle brackets.

A possible fallback _might_ be to define specializations with a
Schema design pattern that makes good use of Schema type inheritance
and to implement an XSLT script that converts the source Schema into
a simple, monolithic Schema definition that most existing tools
can support.  That way, we might

*  Take advantage of the best design pattern for the
  specialization definition.

*  Continue to advocate for tool support for advanced Schema
  features (possibly offering the source code for the DITA
  core specializations as test cases).

*  Support current tools in the interim.

But that conversion script might take some effort to implement.

Because of the need for idiomatic design patterns and, thus,
the absence of an automated conversion, we need to maintain
the core DITA vocabulary manually in both DTD and Schema.  
Declaring both to be normative runs the risk of confusion
if there's a mistake that's syntactically valid but
semantically or structurally incorrect.  Better to have one
unambiguous authority so at least all implementations will be
consistent.  DocBook still has one normative implementation
even though DocBook has been implemented in multiple schema
languages for years.

The DITA DTDs have seen much more use and attention than the
Schemas.  (Even so, there have been flaws.)  Because of the
greater attention and the stability of DTD implementations,
DTDs pose less risk than Schemas.

All that said, I for one would very much like to see DITA
enhanced with a namespace scheme.  We would need to find a
good way to do it and to avoid delay because of it.


A long-winded response - what do others think?


Erik Hennum
ehennum@us.ibm.com