RE: [dita] DITA namespace?

["Grosso, Paul" <pgrosso@ptc.com>]

I'm not against namespaces, but they do make me very

nervous, especially when they get introduced into

existing vocabularies--because they, by definition,

create a new vocabulary.

 

DITA 1.0 does have the DITAArchVersion attribute in the

http://dita.oasis-open.org/architecture/2005/ namespace.

 

And I thought folks like Eliot agreed that was enough to

allow him to recognize DITA content and reference schemas

as needed.

 

So in what way do you mean "DITA doesn't have a namespace right now"?

 

And in what way do "tools that depend on namespace to associate a document

with its schema" still "probably do need one"?

 

I'm not sure how to answer #1 and #2 below, but I would point

out that #2 (processing) includes more than just the official

toolkit.  There are users out there writing their own code

(XSLT and otherwise), and not all that code will work without

modifications (or complete rewrites) if we add namespaces.

 

I'd like to have a better idea just what the advantages

are of adding namespaces so that I can make a better

cost/benefit analysis.  Right now, I see lots of costs,

but I don't have a good understanding of the potential

benefits.

 

paul

---

From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Tuesday, 2006 February 07 11:11
To: dita@lists.oasis-open.org
Subject: [dita] DITA namespace?

There are a lot of tools that depend on namespace to associate a document with its schema or processing. DITA doesn't have a namespace right now, but we probably do need one. The issues are:

1.-would new namespaced content be backwards compatible with tools and editors?
2. could processing handle a mix of namespaced and non-namespaced DITA content?
3.  what do we tell specializers to do?

In an ideal world, it would be nice to have a separate namespace for every DITA specialization: but the issue we had with that in our previous discussion was the usability of a compound document that would include so many different namespaces, and the inability to default more than one of them.

If we can answer 1 and 2 in the positive, maybe the position for 1.1 could be:

- provide a single "dita" namespace for all base DITA markup (eg topic, task, concept, reference, various domains)
- if necessary, provide an un-namespaced version as well, for backwards compatibility with any existing tools/implementations
- tell specializers to either create their specializations in the existing "dita" namespace, or in no namespace, or in their own namespace, at their discretion (as long as the result can still be processed and edited as DITA topics based on class attributes etc.)

And defer to the future the question of whether we can overcome the technical and usability challenges involved in synchronizing namespaces and design modules in DITA, ie having the topic type or domain name as the automatic namespace for any specialization.

Michael Priestley
IBM DITA Architect
Classification Schema PDT Lead
mpriestl@ca.ibm.com