Re: [dita] DITA namespace?

["Eliot Kimber" <ekimber@innodata-isogen.com>]

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

ekimber@innodata-isogen.com
www.innodata-isogen.com