This proposal does not yet have an issue number because we have
not yet decided to pursue this issue. Please read the proposal with an eye toward
discussing that at a TC meeting (or in email).
There are also some design choices described herin.
DITA
Proposed Feature # XX
Extensibility
of DITA through new attributes
Longer
description
XML's two extensibility
mechanisms are elements and attributes. As its name implies, extensibility is
one of XML's key design criteria. Extensbiility (through specialization and
customization) is also a key part of DITA's design. But DITA only allows the
definition of new elements, not new attributes, through specialization. There
are a variety of reasons that people might wish to add their own attributes
(discussed in the Use Case section).
Scope
Trivial, if attribute
extension is deemed to be orthogonal to specialization. Potentially major if
the two features need to be integrated.
Use
Case
- Consider a CMS which
needs to add attributes to an element to track its object identifier
within the CMS. Other processes based upon standard APIs and stylesheet
languages can safely ignore the attribute. But the CMS may really need it.
- Consider a
specialization for software documentation. For internal purposes, it may
be important to link each feature description to the internal
specification document so that changes in the specification can be
reflected in the documentation. To make this work, each element should
also have a date change attribute.
- Consider a
specialization for a product catalog. It might need to refer to
company-internal product numbers in order to synchronize with a product
database.
DITA itself does not
prevent organizations from customizing it with extra attributes of this sort.
In fact, it cannot prevent this. These sorts of customizations already exist.
What the specification can do is license or proscribe it. If it allows it then
attribute-bearing documents will work seamlessly with DITA-based software. If
it proscribes it then DITA-validating programs may give error messages about
otherwise-harmless attributes.
The following use cases
are not addressed by this feature:
- Specializations of
existing DITA attributes (e.g. @otherprops, @conref, @href etc.).
- Specializing
attributes as elements or vice versa.
Technical
Requirements
The most basic proposal is that the DITA spec
simply state that document types of DITA may add attributes to specialized
elements and base DITA elements. This would require no change to any existing
documents or applications. It would imply no additional work on behalf of DITA
implementors. The downside of this proposal is that it would imply that
attributes added in this way would be lost during the generalization process.
The writer does not know of any applications that would be harmed by this
situation.
If DITA's design has a
hard requirement that the generalization process be lossless then that would
imply that some form of attribute specialization is required. This advanced proposal would most likely
take the shape of allowing attributes to specialize elements.
Costs
In the basic form the
costs are minimal. In the more complicated form, we would need to agree on a
specialization mechanism and implement it in the DITA toolkit and all
generalization/specialization implementations.
Benefits
I believe that most large
organizational implementations of DITA will want to add attributes, if only to
use DITA in content management systems that require it. In fact, they will add
attributes, whether the DITA specification allows it or not (as organizations
do with Docbook, AECMA and other standard DTDs). If the DITA specification
disallows this, and DITA software enforces this policy then organizations will
have to write programs to strip these attributes before sharing these documents
with their business partners.
Time
Required
At the low end (basic
proposal), one hour. At the high end (advanced proposal), more than a week of
work.