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

What I would like to see is a walkthrough
of how the new attributes would be preserved through generalization/respecialization,
and how transforms/processes that target the attributes could work with
the generalized form.

A concrete example of this behavior
with existing DITA content is:

- generalize all types to topic base

- translate using generalized document
type and non-DTD-aware tools

- publish using specialized transforms,
without needing to respecialize

Michael Priestley



Dana Spradley <>

08/31/2005 01:40 PM

To

JoAnn Hackos <>

cc

Paul Prescod <>,


Subject

Re: [dita] DITA Proposed
Feature: Extensibility of DITA through new attributes

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

1.        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. 

2.        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.

3.        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:

1.        Specializations
of existing DITA attributes (e.g. @otherprops, @conref, @href etc.). 

2.        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.