[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 ekimber@innodata-isogen.com www.innodata-isogen.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]