Re: [dita] DITA namespace?

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

Michael Priestley wrote:
> 
> 1) Creating an additional layer of the specialization hierarchy to 
> enable namespaces would mean that all future specializations would have 
> to pick one or the other specialize from. That creates a bit of a 
> problem: my "specialtask" is a kind of DITA "task", but not a kind of 
> "dita:task"?

I don't think there can be any confusion about which to specialize from 
*if you are using namespaces*: use the namespaced version. If you are 
not using namespaces then you should only specialize from the 
no-namespace version.

That also implies that once a namespaced version of the DITA types is 
defined that use of unnamespaced version should be discouraged--the only 
real reason to use it would be if you needed for some reason to create 
unnamespaced extensions (that is, for some reason you were so limited by 
your tools that you could only use unnamespaced elements; a case that 
will be less and less common as non-namespace-aware tools are upgraded 
or replaced).

> 2) Extensions to DITA are not the same as extensions in other 
> architectures. They are still DITA, and are still processable as DITA, 
> if they followed the namespace rules. So it's not so weird to allow them 
> in the namespace if they want in. If DITA is the only architecture to 
> allow that, it's because we're the only architecture that has 
> specialization currently.

We clearly have a very different idea of what it means to "be DITA". As 
far as I'm concerned DITA is the types and semantics defined in the 
OASIS spec *and nothing more*. All non-DITA-defined specializations are 
"DITA-based" applications, but they are not "DITA" unqualified.

Therefore I cannot possibly agree with this assessment: as far as I am 
concerned it is just plain wrong (and goes some way to explain why we 
disagree on the current rules for constructing specialized DITA-based 
DOCTYPE declarations).

> I'm also not convinced on the general authorability of a mixed-namespace 
> document. I don't think we can expect authors to be namespace aware, 
> given that we can't even reliably expect tools to be.

I see it this way: if you use the namespaced version of any application 
then you are stepping up to living in a namespaced world (the world of 
modern XML) and therefore you must be at least minimally namespace 
aware--both the humans and tools in the system.

If your tools and/or humans are incapable of living in a namespaced 
world, then stay in the no-namespace world, which will be available for 
quite a while (because DITA 1.0/1.1 exists only in the no-namespace 
namespace).

I think namespaces are hardest for people who grew up before namespaces. 
But anyone coming new to XML today will encounter namespaces from the 
first go and will simply accept them as a part of the world ("Daddy, how 
did you live before there were namespaces?")

   And from an
> authoring point of view, why should I care where the element came from, 
> if it's relevant to my authoring task? The fact that my local tools team 
> created a specialized domain for my use isn't important to the author, 
> and it forces an artifact of the design process (ie when and where the 
> element was created) into the author's space.

It might be very important because bib:name is very different from 
func:name.

> How about a compromise on this point: we recommend specializers use 
> namespaces, but don't require it? And we don't define rules for the 
> namespace in 1.1, eg if a company is creating twenty specialization 
> modules, they wouldn't need to create twenty namespaces.

I'm sorry but I can't agree to this--I stand firm on my position that 
once DITA defines namespaces for itself that these namespaces are 
closed. As for specializers, they are free to do whatever they want in 
terms of allocating their specialized elements into *one* or more 
namespaces.

That is, if I create two different specializations of topic I could put 
those in one namespace (that I own) or two namespaces (that I own). 
Which I do would be up to me based on the semantics and practicalities 
of what I'm doing, not on DITA-defined rules. We can certainly suggest 
what we think best practice is, but beyond requiring the use of 
namespaces, I don't it's necessary or appropriate to require more.

Cheers,

E.
-- 
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