Re: [dita] DITA namespace?

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

Michael Priestley wrote:

> 3.  what do we tell specializers to do?

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 define 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"

(I think that's the right syntax for class=--I couldn't quickly find the 
documentation for how to construct class values).

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 
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, schemalocation 
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).

Cheers,

Eliot
-- 
W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(512) 372-8841

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