dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [dita] Specialization of Attributes
- From: Michael Priestley <mpriestl@ca.ibm.com>
- To: "Paul Prescod" <paul.prescod@blastradius.com>
- Date: Thu, 20 Apr 2006 10:45:47 -0400
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]