Re: [dita] Controlled values, @collection-type enumerations and glossaries

Erik Hennum <> 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