Re: [dita] DITA Proposed Feature: Extensibility of DITA through newattributes

I'm going to have to miss the next meeting or two
as well, and would also like to voice my support for this proposal, in
either its basic or advanced form.

--Dana

JoAnn Hackos wrote:

  
  
  

  
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.