OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [dita] Specialization of Attributes


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

ekimber@innodata-isogen.com
www.innodata-isogen.com



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]