Re: [dita] Proposal for DITA namespaces

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

Erik Hennum wrote:

>>From a processing perspective, such precise typing is
> a good thing.  From an authoring persective, we might
> be able to improve the experience using default
> namespaces on each element instead of the prefixes.

But my point is that the element type names don't matter, so, from a 
processing perspective, the qualification of the element type names by 
their specialization package doesn't help (but it doesn't hurt either).

The reason I originally proposed two namespaces, one for maps and one 
for all the content stuff (topic and it's DITA-defined specializations) 
was that syntactically they are currently defined as a single namespace 
(really, the no namespace) and there didn't seem to be any obvious 
advantage to further distinguishing them at the elemen type level, 
especially given that the task/concept/reference specializations did not 
modify the core content element rules at all.

Also, since the DITA base has been and will presumably continue to be 
defined as a single coordinated development activity, any name conflicts 
across DITA-defined specializations can be avoided, removing the need to 
use namespaces simply to disambiguate names in different DITA-defined 
specialization packages. Thus again, no strong need to have one 
namespace per DITA-defined specialization package.

If we accept the assertion made on this week's con call that many DITA 
users will just use the DITA base stuff and never specialize, which I 
think is likely, then as that type of author (which I sometimes am) I 
would find the various namespaces very distracting because it wouldn't 
help me, as an author, do a better job of authoring--from my perspective 
as an author topic, task, concept, and reference are all part of a 
single document type and further qualifying them doesn't help me 
understand them or use them any better.

But, for non-DITA-defined specializations I do agree that using 
namespaces there would be indicated as best practice, both to clearly 
distinguish DITA-defined from non-DITA-defined and to avoid name clashes 
with other non-DITA-defined specialization packages over which you have 
no control.

But in that case you're already stepping up to constructing your own 
schema and you'll already have to do the appropriate importing and 
attendant namespace management so it doesn't add to the cost to do that.

Cheers,

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

eliot@innodata-isogen.com
www.innodata-isogen.com