[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
impact.
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
today.
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
point.
> 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
seriously.
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
paranoia).
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
door.
Cheers,
E.
--
W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(512) 372-8122
www.innodata-isogen.com
