dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [dita] Controlled values, @collection-type enumerations and glossaries
- From: Deborah_Pickett@moldflow.com
- To: Erik Hennum <ehennum@us.ibm.com>
- Date: Tue, 20 Nov 2007 11:58:40 +1000
Erik Hennum <ehennum@us.ibm.com> wrote on 16/11/2007
03:35:19 PM:
> I can certainly see the value of declaring a collatable collection
> (reference lists spring to mind), especially one where some of the
> contents of the collection might be added dynamically via <navref>
> or <anchor>.
>
> I have a big concern about putting values that are core to
> processing expectations into a completely rewriteable set. If
> someone adds a new type of platform or more specific part of speech,
> that won't have a fundamental impact on processing, but the linking
> expectations for sequence and family are defined.
Hi Erik,
I see your point of view, but . . . let me put on
my implementor hat for a moment.
As an implementor of the DITA spec, sometimes I have
to do things that are beyond the letter of the spec, but which I feel are
within the spirit of it. I want these things to be, at the very least,
possible to implement. Minimally, there has to be some markup in
the map to indicate to processing that glossary-sorting has to take place
on *this* part of the map. In practice, that comes down to an attribute
on the topicref, or a specialization of the topicref.
As an implementor, I rejected a specialized topicref
because I wanted this behaviour to happen independently of specializations
(regular maps might want glossary sorting, as might bookmaps, as might
some other specialization of map that I haven't invented yet). Java
programmers would recognize this need as the difference between subclassing
and implementing an interface.
So what of attributes? @collection-type is a
closed set. Adding a domain attribute is too universal. I am
reduced to relying on @outputclass and checking for a magical value. (Which
is what I suggested to a user on dita-users who had exactly this requirement.)
In this case, as an implementor, I have achieved my
requirement, but in a dirty way. I wouldn't have to have done this
if I were able to extend @collection-type.
Is there a compromise position? Can DITA take
a leaf out of other standards (MIME and language tags are two that immediately
spring to mind) and allow any value starting "x-"? We implementors
would get what we want, and the DITA TC would have plausible deniability.
--
Deborah Pickett
Information Architect, Moldflow Corporation, Melbourne
Deborah_Pickett@moldflow.com
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]