MHonArc v2.5.0b2 -->
dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [dita] DITA namespace?
From: "Grosso, Paul" <>
To: <>
Date: Tue, 7 Feb 2006 13:47:30 -0500
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:]
Sent: Tuesday, 2006 February 07
11:11
To:
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
