[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] DITA namespace?
From: Grosso, Paul [mailto:pgrosso@ptc.com]
Sent: Tuesday, February 07, 2006 10:48 AM
To: dita@lists.oasis-open.org
Subject: RE: [dita] DITA namespace?I'm not against namespaces, but they do make me verynervous, especially when they get introduced intoexisting vocabularies--because they, by definition,create a new vocabulary.DITA 1.0 does have the DITAArchVersion attribute in theAnd I thought folks like Eliot agreed that was enough toallow him to recognize DITA content and reference schemasas 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 documentwith its schema" still "probably do need one"?I'm not sure how to answer #1 and #2 below, but I would pointout that #2 (processing) includes more than just the officialtoolkit. There are users out there writing their own code(XSLT and otherwise), and not all that code will work withoutmodifications (or complete rewrites) if we add namespaces.I'd like to have a better idea just what the advantagesare of adding namespaces so that I can make a bettercost/benefit analysis. Right now, I see lots of costs,but I don't have a good understanding of the potentialbenefits.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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]