RE: [dita] Specialization of Attributes

[Michael Priestley <mpriestl@ca.ibm.com>]

I think we're overthinking.

1. we know people want to add new attributes
for conditional processing.
2. we know in some cases those new attributes
are refinements of existing ones (eg opsys as specialization of platform,
or jobrole as specialization of audience). 
3. we know people want to do more intelligent
matching based on sets of values rather than single ones (eg exclude windows*).
4. we know some of these values will
matter to taxonomic systems in the future, so we should try to keep some
formality in what we consider a value, but our scheme needs to work without
a taxonomy system as well, and that should be the focus for 1.1

For 1 and 2: current proposal addresses.
We can add new conditional attributes based on props or specializations
of props, and generalize to ancestors when necessary.

For 3: current proposal addresses. Identify
sets of values with a common naming component, eg windows/ 
For 4: current proposal makes no one
happy, because it actually gets some idea of sets of values into the instance,
where it doesn't belong; and because it doesn't allow full wildcard filtering
or boolean expressions.  I think, on this item, compromise is necessary,
we can't please both sides, we can only try to get a compromise that both
sides can live with. I think the current proposal is that compromise.

The remaining questions are related
to generalization: 
- should a ditaval for a specialized
att match against a generalized form? I would argue yes, or it isn't generalization
- should a ditaval for a general att
match against a specialized form? I would argue no, because the alternative
is completely confusing, and because there are workarounds. This is not
a case where we want fall-through processing - a ditaval match is not the
same as a transform.
- does an application need to honour
generalized forms? I would argue yes, but I think we can probably compromise
by differentiating between final-output applications (which should honour
it) versus preview output applications (which could choose simply to flag
it as too complex for evaluation by a previewing application)





Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25

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

04/20/2006 02:02 AM

To	"Erik Hennum" <ehennum@us.ibm.com>, <dita@lists.oasis-open.org>
cc
Subject	RE: [dita] Specialization of Attributes

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