[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] DITA Proposed Feature: Extensibility of DITA through new attributes
In my opinion, Paul has stated this requirement very well.
I would like to see the more complex version implemented based on my reading of
his argument.
Since I'm on my way to Australia for two weeks and will
miss the next few meetings, I wanted to go on recording supporting this
concept.
JoAnn JoAnn T. Hackos, PhD From: Paul Prescod [mailto:paul.prescod@blastradius.com] Sent: Monday, August 29, 2005 12:51 AM To: dita@lists.oasis-open.org Subject: [dita] DITA Proposed Feature: Extensibility of DITA through new attributes 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
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:
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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]