OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [dita] Proposal for DITA namespaces

[NOTE: I'm posting the following note mostly to capture the thoughts but 
the discussion may be moot if my idea in the 3rd para below pans out. 
I'll post separately on that idea. WEK]

Paul Grosso wrote:

>>1. Does DITA need namespaces? I say "absolutely", Erik is 
>>saying "very 
>>probably". I'm not sure if there is wider concensus one way 
>>or the other.
> I'm saying, not for 1.0.  
> In developing the charter for this TC, we said the idea for 1.0 
> was basically to "rubber stamp" the existing IBM DITA stuff.  I 
> fear adding namespaces is not that trivial an addition.

Would it be possible to define one or more DITA namespaces but not use 
them in the DOCTYPE-based form of the document type definitions? That 
is, establish a normative namespace but allow people to continue the 
status quo if they so desire? I'm not sure what the implications for 
generic DITA processors would be in that case.

If one uses the DITA namespace as the default namespace for a document 
and you have no local specializations in a different namespace then 
there is no syntactic difference between a document that uses namespaces 
and one that doesn't, except for the namespace declaration itself. So 
from that standpoint I think that namespaces could be used with minimal 

Another option might be that the *only* thing that's namespaced in a 
DITA 1.0 document is the DITA class attribute--that would be sufficient 
to unambiguoulsy establish that a document was a DITA document but 
otherwise completely avoid issues of what real name space a given 
element type comes from or how the DITA correctness of the documents is 
established (e.g., through DTD declarartions, schema tricks, or some 
separate validation application).

Essentially, the current DITA mechanism essentially says that all 
elements in a DITA-based document are in the same namespace *because 
they all are declared in the same declaration set* and are not otherwise 
distinguished or distinguishable. This could be continued in a 
namespace-based DITA system in 1.0 simply by requiring the same 
*syntactic* inclusion of specialized element types that DITA requires 

But having said that I appreciate Paul's position and it may be the only 
practical approach to take in order to meet our schedules.

I think the use of schemas and namespaces provides the opportunity to do 
specialization and modularization in a more sophisticated way but I 
don't think that the use of namespaces *requires* that sophistication. 
That is, I think it is entirely possible to define a namespace-based 
form of DITA that is exactly equivalent to the current DITA.

So as we evaluate what we can do we need to be careful to separate out 
the unavoidable cost from the potential cost of trying to do new things 
in the short term. On that point I agree with Paul that we must be 
ruthless in avoidance of trying to refine or extend current DITA. But I 
am proposing that the simplest use of namespaces does not in fact refine 
or extend DITA as it is today beyond simple qualification of the 
existing names.

>>2. If there are name spaces, how many and how will they be 
>>used? This is 
>>very much an open question and will require experimentation 
>>and thought. 
> I agree--another reason I'd rather wait until after 1.0.

If we cannot come to a clear understanding quickly then I will have to 
agree. But the more I think about it the more I think there might be a 
simple near-term use, as explained above.

>>And I will re-iterate my position on the need for namespaces, 
>>irrespective of the element type declaration mechanism used: 
>>there is no 
>>other standard way in XML to unambiguously declare that a document 
>>conforms to a particular set of rules. 
> Yes there is.  We say so.  DITA is working now for many people.

DITA *as it exists for me* DOES NOT WORK for my content management 
application that wants to be able to do generic import of DITA-based 
documents. That is, without a namespace declaration in a document 
instance, my generic processor *cannot know* that a give document is in 
fact a DITA document.

That means that either the user must explicitly say, for each document 
to be imported, that it is in fact a DITA document or my code has to 
guess based on unreliable clues, such as the root element name or the 
external identifier in the DOCTYPE declaration (should there be one). 
Neither of these are reliable in the general case.

Obviously in a specific case one can reasonably assume that a document 
with root element <topic> that points to "../dita/topic.xsd" is probably 
a DITA document, *but it's not testable*. That is, there is no 
characteristic of that document that I can examine to unambiguously 
determine if it is in fact a DITA document--there are any number of ways 
I could get false negatives or false positives.

In a formal spec "guessing is good enough" is not acceptable. That's my 

> While I don't disagree that adding namespaces may be useful
> in the future, I fail to see how it is a disaster to have DITA 1.0
> be what DITA is currently.  In fact, I fear it will be a bigger
> disaster to make DITA 1.0 something that is non-trivially
> different from what is already deployed in many places.

Like I said, I appreciate Paul's concerns and we need to take them 

My counter is that schemas and namespaces are now the dominant and 
expected technology in the XML world. If we want to have spec that is 
taken as seriously as we want it to be and that is well prepared for the 
future I think it needs to be namespaced and have at least a 
solidly-constructed, if not normative, schema associated with it.

While we did agree to essentially publish the IBM submission as is, I 
think we run the risk of it being perceived, at least in some quarters, 
as just "old IBM SGML think". I'm not saying that it is or that that 
would be a fair assessment--just that having been the victim of that 
sort of thinking myself I am sensitive to it (perhaps to the point of 

Certainly I would expect that for any XML implementor younger than say 
30 coming to a spec like DITA for the first time, that the first thing 
they would do is look for the namespace to use and then ask "where is 
the schema?". I think this is especially true in a world where tools 
like Word 2K3 can only use namespaced schemas [which, strangely enough, 
I don't find offensive--can that be right?].

I know from having worked with Paul for many years that he and I tend to 
fall at opposite ends of the caution vs innovation spectrum and I 
respect Pauls many battle scars earned getting a number of specs out the 



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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]