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] Controlled values, @collection-type enumerations and glossaries

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

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