Re: [dita] DITA namespace?

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

Hi, Committee Folk:

Support for namespaces seems like a prerequisite for DITA to participate in componentization initiatives, which generally require namespaces to avoid naming collisions during integration -- that is, to allow a DITA topic as a content object embedded within a larger non-DITA structure (such as a SOAP envelope or a W3C Compound Document Format).

Long term, we might treat namespaces as a special case of aliasing (the feature that Eliot and others have suggested - a way to assign a different element name to an element type within a document type). Once we can recognize <p> and <para> as two different names for the same fundamental element type (topic/p), we should be able to recognize <dita:p> as one more name for the same element type.

Obviously, we can't require a namespace -- that would break the DITA 1.0 inventory. Thus, for DITA 1.1, I'd propose offering the core document types in two versions:

* Unqualified as they are currently
* Qualified with a namespace for DITA vocabularies such as http://dita.oasis-open.org/vocabulary/2006/ (using "dita" as the conventional prefix)

In DITA 1.1, we would specify the two variant names (<p> and <dita:p>) as equivalent and note that, in DITA 2.0, we might add a general-purpose aliasing mechanism that can provide a formal declaration of equivalence.

I've appended a few other comments, but that's the big potato.


Hoping that's useful,


Erik Hennum
ehennum@us.ibm.com

----------------------------------------
Additional comments:


IMPLEMENTATION: The XML Schema import statement can apply a namespace to elements without a namespace, so that offers an easy implementation. On the DTD side, we could add a namespace entity to the attribute list for every element, default that namespace entity to nothing, but set the namespace in an including file. So, again, the implementation would be easy.

Processes that look only at the class attribute wouldn't be affected. Processes (such as generalization and respecialization) that correlate the element name with the class attribute token might need to ignore the namespace prefix on the element name.


SPECIALIZED ELEMENTS: As we've discussed and (I think) provisionally agreed, DITA 2.0 would benefit from having a namespace associated with each module and using the combination of the module namespace and the element type name as an unambiguous universal identifier for the element type.

If we introduce an optional DITA vocabularies namespace for elements in DITA 1.1, that namespace won't conform to this proposed DITA 2.0 module-based scheme. But, again, we can handle that problem with aliases. That is, in DITA 2.0, the canonical name for an element could be the element type name in the module namespace (<topic:p>). In DITA 2.0, two standard aliases could be the element type name in no namespace (<p>) or the element type name in the DITA vocabularies namespace (<dita:p>). That way, a DITA 2.0 module-based scheme wouldn't break DITA 1.0 or 1.1 inventory.

If DITA 2.0 takes that approach, DITA 1.1 can allow DITA specializations to add their elements to the DITA vocabularies namespace. Those elements will be no more at risk for naming collisions than they are currently. Usability is improved because the namespace can be set once on the topic element, regardless of how many specializations are included. And, that gives us a simple fix for tools whose imperfect namespace implementation can't recognize DITA content based on the architecture attribute.

To expand on the usability problem, because extension by substitution interleaves elements from different specialization modules, the module associated with an element can change on an element by element basis. If we require a namespace on each specialization module (whether declared with defaulted or prefixed namespaces), the namespace could change on an element by element basis. That could increase the XML noise for writers. So, a better approach for DITA 1.1 is to leave it up to the specialization whether the specialized elements are more usable in their own namespace (<gloss:entry>) or in the DITA vocabularies namespace (<dita:glossentry>).