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: Michael Priestley <>
To: "Eliot Kimber" <>
Date: Fri, 10 Feb 2006 12:49:04 -0500
1) Creating an additional layer of the
specialization hierarchy to enable namespaces would mean that all future
specializations would have to pick one or the other specialize from. That
creates a bit of a problem: my "specialtask" is a kind of DITA
"task", but not a kind of "dita:task"?
2) Extensions to DITA are not the same
as extensions in other architectures. They are still DITA, and are still
processable as DITA, if they followed the namespace rules. So it's not
so weird to allow them in the namespace if they want in. If DITA is the
only architecture to allow that, it's because we're the only architecture
that has specialization currently.
I'm also not convinced on the general
authorability of a mixed-namespace document. I don't think we can expect
authors to be namespace aware, given that we can't even reliably expect
tools to be. And from an authoring point of view, why should I care where
the element came from, if it's relevant to my authoring task? The fact
that my local tools team created a specialized domain for my use isn't
important to the author, and it forces an artifact of the design process
(ie when and where the element was created) into the author's space.
I think there will be cases where a
specializer wants to use a namespace, because it's convenient and adds
semantic value to the author. But there will be plenty of other cases where
the namespace would just be noise, and it makes sense to me that the specializer
would choose not to distinguish in that case.
How about a compromise on this point:
we recommend specializers use namespaces, but don't require it? And we
don't define rules for the namespace in 1.1, eg if a company is creating
twenty specialization modules, they wouldn't need to create twenty namespaces.
Michael Priestley
IBM DITA Architect
Classification Schema PDT Lead
"Eliot Kimber"
<>
02/10/2006 10:56 AM
To
<>
cc
"Erik Hennum" <>
Subject
Re: [dita] DITA namespace?
Erik Hennum wrote:
> Long term, we might treat namespaces as a special case of aliasing
(the
> feature that Eliot and others have suggested - a way to assign a
> different element name to an element type within a document type).
Once
> we can recognize <p> and <para> as two different names
for the same
> fundamental element type (topic/p), we should be able to recognize
> <dita:p> as one more name for the same element type.
We can already do that--it's what the class attribute does. That is, if
you define the element type myns:foo as a specialization of topic/p then
at the level of DITA-aware processing is *is* a topic/p and therefore,
for the purpose of DITA-aware processing, myns:foo is an alias for
topic/p. The fact that myns:foo may have additional, non-DITA semantics
in the context of myns-aware processing is irrelevant to this discussion.
Or said another way: you can always get aliases by adding another level
of specialization.
I don't think that having aliases *at the same level of specialization*
is sensible (and it's unnecessary in any case).
> In DITA 1.1, we would specify the two variant names (<p> and
<dita:p>)
> as equivalent and note that, in DITA 2.0, we might add a general-purpose
> aliasing mechanism that can provide a formal declaration of equivalence.
This equivalence could be formally established by making one form a
specialization of the other (presumably the namespaced version would
specialize the no-namespace version). This would, in part, allow
namespaced documents to still be processed by specialization-aware DITA
1.0 processors.
(This might require that the two DTDs/schemas be syntactically distinct,
which I think would be a good thing because I've always considered the
current rules for constructing specialized DTD declarations to be
unnecessary and pointless.)
> IMPLEMENTATION: The XML Schema import statement can apply a namespace
to
> elements without a namespace, so that offers an easy implementation.
On
> the DTD side, we could add a namespace entity to the attribute list
for
> every element, default that namespace entity to nothing, but set the
> namespace in an including file. So, again, the implementation would
be easy.
I would agree as long as the intent is only to apply the DITA namespace
to the DITA-defined element types and not to non-DITA-defined
specializations (which should never, under any circumstances, be in the
DITA namespace).
> SPECIALIZED ELEMENTS: As we've discussed and (I think) provisionally
> agreed, DITA 2.0 would benefit from having a namespace associated
with
> each module and using the combination of the module namespace and
the
> element type name as an unambiguous universal identifier for the element
> type.
I think the jury's still out on whether or not there need to be multiple
namespaces for the DITA-defined types--at the moment, based on only a
little experience and experimentation, I think it's sufficient to have
a
single namespace for all DITA-defined types. But I wouldn't object to
unique namespaces for the different modules--I don't think it really
changes that much in practice once you've stepped up to namespace
awareness generally.
> If DITA 2.0 takes that approach, DITA 1.1 can allow DITA specializations
> to add their elements to the DITA vocabularies namespace.
I have to object to this proposal in the strongest possible terms. Any
non-DITA-defined specialization is, by definition, not part of the core
DITA document type and therefore should not ever be allowed to claim
membership in the DITA namespace.
This is the problem with the no-namespace namespace (where all current
DITA (and DocBook and ATA 2100 and ...) element types are) is an
inherently unboundable namespace and there's no standard or reliable way
to enforce or validate that a given name is or isn't a member of a given
vocabulary.
But in practice it would be hard to do anyway (put specializations in
the DITA namespace) because (using XSD schema--let us assume that anyone
doing namespace-aware DITA stuff is *not* using DOCTYPE declarations)
you'd have to declare a schema you own (the schema defining your
specializations) as governing the DITA namespace, which would be both
morally wrong (obviously no local specializer governs the DITA
namespace) and potentially problematic if you try to follow the practice
that there should exactly one XSD document for a given namespace (this
practice can't always be enforced because of things like versioning and
use-specific variants and such but I still think it's good to do when
you can).
That is, if we assume that the DITA-defined schemas are read-only (which
they should be as there would be no reason for any DITA user to directly
modify what the DITA TC has provided), then you must be using that
schema by reference. Because it's in a different namespace you can't
include it so you must be importing it, which means that your schema is
either in no namespace (which you just shouldn't do ever) or in your own
namespace.
Those elements
> will be no more at risk for naming collisions than they are currently.
The issue is not name collision but assertion of membership in a fixed
vocabulary defined by a committee.
> Usability is improved because the namespace can be set once on the
topic
> element, regardless of how many specializations are included. And,
that
> gives us a simple fix for tools whose imperfect namespace implementation
> can't recognize DITA content based on the architecture attribute.
Note that for schema-based documents, you could dereference the
document's schema(s) (which useful tools would have to do in any case)
and examine the schemas it(they) imports to see if it imports the DITA
schema, and if it does I think its fair to assume that the document in
question is a DITA-based document (one could import the DITA schema and
never actually use it but I think that false positives are much less
problematic than false negatives--better to try to process a document as
DITA-based and have it fail due to schema-definer error than to fail to
recognize a DITA document as being a DITA document).
> To expand on the usability problem, because extension by substitution
> interleaves elements from different specialization modules, the module
> associated with an element can change on an element by element basis.
If
> we require a namespace on each specialization module (whether declared
> with defaulted or prefixed namespaces), the namespace could change
on an
> element by element basis. That could increase the XML noise for writers.
> So, a better approach for DITA 1.1 is to leave it up to the
> specialization whether the specialized elements are more usable in
their
> own namespace (<gloss:entry>) or in the DITA vocabularies namespace
> (<dita:glossentry>).
I have to disagree--I feel strongly that any supposed usability issues
are overridden by the need to maintain the clear separation between
DITA-defined types and user specializations. I know of know other
XML
application standard that defines a namespace that also allows
non-standard-defined elements to claim membership in that namespace.
Quite the opposite--they go to pains to explicitly disallow it.
For example, if a vendor provided a built-in specialization module that
only their product supported and that they didn't license the use of
beyond the scope of their product and put those specializations within
the DITA namespace there would be no way for a naive user to distinguish
the DITA-defined elements from the vendor-proprietary elements.
Also, I am yet to be convinced that changing namespaces really causes
that much noise for namespace-aware authors, except possibly for those
using XML text editors, which I still think must be a relatively small
number of current and potential DITA authors.
That is, as long as you're cool with prefixes (which I think any
namespace aware XML author has to be) then it is sufficient to declare
all the prefixes you need on the root element (or some convenient
ancestor, depending on the nature of the document) and go from there.
And again, this is only an issue for editors that don't hide namespace
declaration attributes.
Cheers,
Eliot
--
W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(512) 372-8841
www.innodata-isogen.com
Follow-Ups:
Re: [dita] DITA namespace?
From: "Eliot Kimber" <>
References:
Re: [dita] DITA namespace?
From: "Eliot Kimber" <>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
