MHonArc v2.5.0b2 -->
dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [dita] Specialization of Attributes
From: "Eliot Kimber" <>
To: "Erik Hennum" <>
Date: Wed, 19 Apr 2006 13:58:57 -0500
Erik Hennum wrote:
> 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.
I don't see that at all.
As I understand the general requirement (and it's certainly a
requirement my constituency has) and as I read the proposal it is to be
able to define entirely new condition attributes with arbitrary values,
that is, conditions that are unique to a particular business process and
may have no useful relationship to any existing DITA-defined condition
attributes.
For that requirement it is sufficient to simply declare that a given
attribute is in fact a condition attribute--no more needs to be said
because no more needs to be known. Everything you need to know in order
to do processing that applies the conditions is provided in the DTD or
in the instance (that is, the name of the condition attributes and the
values *actually used* in the instance data).
If there is a further requirement to be able to specialize *existing*
condition attributes and values such that the semantic relationship
between the general attributes and values and the specialized attributes
and values is somehow known, that is a very different thing and one that
is unavoidably difficult because it strays into the arena of taxonomy
and philosophy.
Conditions, especially those that directly reflect the details of a
specific business process, industry, or type of thing are inherently
limited in their utility for interchange and interoperation, for the
simple reason that the *business process* is itself singular. Even
something as simple as how a given enterprise classifies "platform" will
vary in incompatible ways from enterprise to enterprise (and likely
within enterprises as well).
If there exist communities of interest that intend to interchange DITA
content and that also need to have interoperation of conditions then it
is encumbent on those communities to define sets of condition attributes
and values that reflect the needs of those communities and represent
agreements between them. The proposal as made provides for that just fine.
While it might, in principle, be possible to define some mechanism
whereby you can specialize condition attributes and values in some
useful way as Erik describes, it seems highly unlikely that we could
either define a workable mechanism in the time we have and unlikely that
many users would in fact use such a mechanism given that it's simpler to
simply agree on a set of conditions when you do need to interchange.
Therefore I have a hard time accepting semantic specialization of
condition attributes and values as either a strong requirement or, if it
is a requirement, as something we can do in the 1.1 time frame.
Cheers,
Eliot
--
W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(512) 372-8841
www.innodata-isogen.com
