OASIS Darwin Information Typing Architecture (DITA) TC

Hi,

I'm sure Eliot and Erik know the answer
to this, but I have a followup question that I'd like to discuss with everyone.

The @collection-type attribute is an
enumeration in 1.1 (with possibilities unordered, sequence, family, choice).
 Will DITA 1.2 relax this so that specializers can add new collection-type
values?  (I am assuming from #12022 and #12031 that the answer is
"yes", but I want to confirm that.)

I am thinking, in particular, of a collection-type
on the parent topicref of a set of glossentry topics, which would indicate
to implementations that the descendants form a glossary set.  Implementations
could use that indication to (say) sort the entries, concatenate entries
that have the same title, construct a mini-TOC page, etc.  Of course,
such processing is none of DITA's business, but there is a real need for
this kind of thing (see a discussion this week on dita-users), and it seems
to me that @collection-type is the right place for such a thing.

--

Deborah Pickett

Information Architect, Moldflow Corporation, Melbourne

Deborah_Pickett@moldflow.com

Hi, Deborah:


As currently specified, the controlled values proposal takes a conservative approach and only proposes binding to selection attributes.


However, the learning specialization and glossary enhancements both provide cases for controlled values beyond the selection attributes, so that limitation is probably artificial and doesn't gain much in simplicity anyway.


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.



What do you think?



Erik Hennum

ehennum@us.ibm.com



Deborah_Pickett@moldflow.com wrote on 11/15/2007 03:39:12 PM:

>

> The @collection-type attribute is an enumeration in 1.1 (with

> possibilities unordered, sequence, family, choice).  Will DITA 1.2

> relax this so that specializers can add new collection-type values?

> (I am assuming from #12022 and #12031 that the answer is "yes", but

> I want to confirm that.)

>

> I am thinking, in particular, of a collection-type on the parent

> topicref of a set of glossentry topics, which would indicate to

> implementations that the descendants form a glossary set.  

> Implementations could use that indication to (say) sort the entries,

> concatenate entries that have the same title, construct a mini-TOC

> page, etc.  Of course, such processing is none of DITA's business,

> but there is a real need for this kind of thing (see a discussion

> this week on dita-users), and it seems to me that @collection-type

> is the right place for such a thing.

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