RE: [dita] Specialization of Attributes

["Paul Prescod" <paul.prescod@blastradius.com>]

The problem with all of these examples is that they imply that specialization _of conditional attributes_ is somehow related to specialization of _conditionality values_. But DITA defines no mechanism for even defining, much less specializing, conditionality values.

 

I would be surprised if we come to a conclusion on these tricky taxonomic issues in time for DITA 1.1. As Eliot said, we are getting into an area "that is unavoidably difficult because it strays into the arena of taxonomy and philosophy."

---

From: Erik Hennum [mailto:ehennum@us.ibm.com]
Sent: Wednesday, April 19, 2006 10:05 AM
Subject: RE: [dita] Specialization of Attributes

Hi, Attribute Specialization Enthusiasts:

Just to check agreement -- a selection attribute provides an enumeration of controlled values. In specializing a selection attribute, we are defining either a subset of the enumeration or defining a new value whose semantic is a subset of an existing value.

As we've discussed before, one example would be a specialization of the platform enumeration:

platform
machine
intel
macintosh
operatingSystem
linux
windows
  
Here, we're dividing an existing enumeration into two separate enumerations. That is, macintosh and intel are not operating systems nor are linux and windows machines. All are still distinct platform values, but a more specific enumeration can also be specified.
 

Putting these values into the same enumeration was simply a modelling error. If a thing can be both Intel and Linux then putting those in the same attribute is simply mistaken according to DITA's model of orthogonal attributes. Specialization will not correct the modelling error but merely work around it for specialized documents.

A better argument for specialization as subsetting would be to simplify a long list of (e.g. operating systems) that is standardized at the high level of a big organizatoin.

By contrast, here's a specialization of the programmer and user values:

audience
programmer
applicationDeveloper
systemArchitect
user
decisionMaker
technicalSupport

In the audience case, we still have one enumeration. A systemArchitect and a decisionMaker are distinct roles within a single enumeration of potential audience roles. We're just saying that applicationDeveloper is a special kind of programmer. 

I could buy this example. The specialization is truly getting more specific. But in order to make it work, you need a language in which you can define that a systemArchitect is a kind of programmer and a technicalSupport person is a kind of user. More generally, what you are saying is that the "technicalSupport" flag implies the "user" flag and the "systemArchitect" flag implies the "programmer" flag.

But anyhow, I still think that talking about specializing conditionality _values_ is out of scope for DITA 1.1, and without it, specialization of conditionality attributes does not make much sense.

 Paul Prescod