Re: [dita] Specialization of Attributes

[Dana Spradley <dana.spradley@oracle.com>]

I agree with Paul: "I'm not even sure whether it is meaning to talk about properties as having an "is-a" relationship to other properties."

In theory, DITA treats elements like programming languages treat objects. In this metaphor, it seems to me that attributes should be thought of like Java variables: not objects themselves, but just part of the object's interface.

Unfortunately, because the DITA object hierarchy is an "is-a" hierarchy, and doesn't support "is-like-a" relationships, you can't extend this interface by adding a new attribute/variable to the element/object.

The solution we are considering for adding attributes while preserving an exact identity between the element before, and the element after this attribute is added should be considered, then, not some other avenue of inheritance peculiar to attributes - but basically nothing more than a kludge, to make up for the fact that we don't allow arbitrary attributes to be added.

The question I have is: do we really need such a kludge - especially when it comes to general, non-conditional attributes?

Couldn't the DITA toolkit merely make it a design principle that any unrecognized attribute should just be ignored?

I also think the reason this issue provokes so much discussion - and has prompted Michael to run through so many hoops in the design - is that some people (myself included) came to DITA hoping to find, not an architecture that would allow round-tripping of documents defined according to slightly different DTDs - but rather an architecture that made customization easier to manage through some kind of "extension" mechanism - and into which today's customizations might become part of the base language in the future - the way, for example, regular expression libraries eventually found their way into the Java base.

It seems that DITA has already made the decision between these two paradigms - and that maybe it should change it's name to, say, IDITA, the "Intelligent Design Information Typing Architecture" - the base is so well designed that we don't need to extend it, just find our specialized place within it.

Maybe another group will come along with a truly extensible DTD/toolkit someday. If so, perhaps "evolution" would be a fitting name.

--Dana


Paul Prescod wrote:

Here's what I think that Erik wants:

Given:

programmertype specializes role
role specializes audience

A filter on "audience='javaprogrammer'" should match content marked
"programmertype='javaprogrammer'"

But consider the complete implications of this. If audience specializes
props then "props='javaprogrammer'" will also match. This implies that
ALL values live in a single namespace. direction="left" and
politics="left" would collapse down to the same thing. Nor is it just a
namespace issue. Remember that DITA treats two values in the same
attribute (OR) differently than it does two values in different
attributes (AND). With attribute specialization we have some kind of
in-between world where attributes are kind-of in the same attribute and
kind-of in different attributes.

Michael's proposal is that from a matching point of view it is totally
irrelevant that programmertype specializes role or that role specializes
audience. He says that the specialization information might be used
somehow but not by the standard matching algorithm. This seems too fuzzy
to me and also dangerous in that it encourages people to use the
undefined feature. When we come up for a meaning for it (perhaps based
upon Erik's ideas) then it will be too late to redefine the behaviour.
Better to outlaw it until we understand it.

This would also go for generic attributes.

I'm not even sure whether it is meaning to talk about properties as
having an "is-a" relationship to other properties. Mainstream
programming langauges certainly have no such concept. More often there
is some kind of a "derived-from" relationship but these are typically
quite complex. "Color" can be derived from "Red", "Green" and "Blue".
Age can be derived from "Date born". But now we're into the semantic
web, not DITA.

 Paul Prescod