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 
President 
Comtech Services, 
Inc. 
710 Kipling Street, Suite 400 

Denver, CO 80215 
303-232-7586 
 
http://www.comtech-serv.com 

From: Paul Prescod 
[mailto:] 
Sent: Monday, August 29, 2005 
12:51 AM
To: 
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

  
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.