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

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

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.

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