To make it easier for information architects who are creating specializations, it helps to have guidelines for specializers.

This guideline speaks in favor of creating a distinctive namespace for the new identifiers in a specialized module. It explains how to do so, and some of the consequences.

The content is based on an e-mail message from Eliot Kimber on February 8, 2006 to the mailing list of the OASIS DITA Technical Committee. Note: this was written quickly, for a language design discussion. Suggestion: edit for a less conversational style.

The content follows:

It seems to me that specializers can do whatever they want: by definition their specializations are theirs and they must be free to put them into whatever namespace they care to (including the no-namespace namespace).

Having said that, my advice to specializers would be to put their specializations in their own namespace always unless their processing system is so namespace unaware that it can't deal with it (in which case they have a much larger problem that we probably shouldn't even be worrying about).

The fact that specializations are in a namespace should have *no effect* on specialization-aware processors because specialization processing is not affected by the element types of the specialized elements, only their DITA-specific attributes. The only implication would be, I think, that in class= attributes, all namespaced names have to be prefixed, irregardless of whether the name is prefixed in the tags.

For example, say I have defined my topic specialization namespace, http://www.drmacro.com/namespaces/mytopic, and have defined the specialized topic type "MacroTopic":

<MacroTopic xmlns="http://www.drmacro.com/namespaces/mytopic">
  ... topic contents
</MacroTopic>

The class attribute for MacroTopic would be:

class="- topic/topic mytopic/mytopic:MacroTopic"

Suggestion: Is the above syntax of the class attribute correct? If so, please remove this note.

And the prefix "mytopic" would have to be declared, either on the element instance or in a separate DOCTYPE declaration, i.e.:

<MacroTopic xmlns="http://www.drmacro.com/namespaces/mytopic"
xmlns:mytopic="http://www.drmacro.com/namespaces/mytopic" >
  ... topic contents
</MacroTopic>

From a practical standpoint, the mixing of namespaces is something of a problem for authors if their authoring tool doesn't hide namespace declaration attributes. If the authoring tool hides namespace declaration attributes, then the only issue is whether or not individual elements are prefixed or not, which should be an author choice that the
authoring tool provides a way to make (or that can be configured as a global preference, for example, depending on how centralized your control of the authoring should be).

That is, once you've accepted namespace awareness as a prerequisite for using XML (which it really is today) then it shouldn't matter to any processing component how the tags are constructed (with or without prefixes).

In addition, how cluttered your XML is with namespace declarations depends on whether you want no prefixes or to have prefixes. If you don't mind prefixes, then you can declare all your namespaces on the document's root element, where there will already be a bunch of other declarative elements (i.e., the root element's namespace, schema location attributes, etc.). If you want no prefixes, then of course each element that establishes a namespace different from its parent must have a namespace declaration attribute, at which point you'd like your authoring tool to hide them for you (which Arbortext Editor and MS Word and I assume XMetal does as well).

Thus, if our concern is for authors having to deal with multiple namespaces, then first we need to recognize that we only really need to worry about those authors using XML text editors as opposed to full-featured editors like Arbortext Editor and XMetal. Second, it's only an issue if those authors expect a completely unprefixed environment.

However, it seems to me that most *current* users of DITA are likely to be larger enterprises that can afford more sophisticated editors, which suggests that users using XML text editors for DITA authoring will be new to DITA (and likely new to XML) and that if the only world they know is one with prefixes that they will be perfectly happy to have prefixes in their tags.

Having said that, I still think that the best thing to do from a practical standpoint is to have one namespace for all of the element types currently defined by the DITA specification. This both reflects the current state (the current DITA specification is effectively a single namespace) and limits any prefixing/local namespace declaration complexity. Any user-defined specializations should be in their own namespace (and not in the no-namespace namespace).

I think that specialized domains should have namespaces distinct from specialized topics as domains and topics are separate axes of specialization that can be combined in different ways and their namespaces should reflect that. Users are already used to having distinct namespaces for highly specialized elements such as math,
linking, and so on.

As a matter of general XML practice, I think it is irresponsible for anyone to create a new document type or schema that is not in at least one namespace and that would, of course, go for new DITA specializations (which are new document types or schema modules).