RE: [dita] 12035 Generic collation element

["Eliot Kimber" <ekimber@reallysi.com>]

It's certainly the case that any given set of topics might be sorted by a special-purpose output processor. Glossary is certainly the most obvious case, but I might sort messages or reference entries or even tasks by title, even if it's in the context of a search result or something.

Thus there is the general possibility that at least topics, if not other elements will be sorted in some processing contexts.

Any time you are doing sorting you have to be able to specify the string to use to control the collation separate from the display text.

Thus there is a general requirement to be able to bind collation keys ("collate as") to text that might be collated, which certainly includes all titles, as well as index terms and probably other things. Since we cannot predict how data might be presented and what the sorting applied might be, it follows that anything that contains text should also allow for a collation spec. For example, I'd like this query to return a locale-appropriate sorted list:

$p in collection()/ditaType("topic")/ditaType("topicbody")//ditatype("p")

Using a subelement is appropriate because it allows for alternative collation keys that apply to different condition sets (for example, I might want to have different collation keys for the same reference entry in English and Japanese, where the reference title is invariant but the way it is indexed is language or locale-dependent).

I would think that if a subelement is used, that we would want to define at least these constraints:

1. Must be a direct child of the element whose text content is being collated

2. There must be at most one effective collation key for a given processing context (that is, at most one following application of any props= values and other filtering processing).

Cheers,

Eliot

----
W. Eliot Kimber
Senior Solutions Architect
Really Strategies, Inc.
512 554 9368


> -----Original Message-----
> From: Grosso, Paul [mailto:pgrosso@ptc.com]
> Sent: Wednesday, August 15, 2007 9:18 AM
> To: dita@lists.oasis-open.org
> Subject: [dita] 12035 Generic collation element
> 
> I am going through the remaining 1.2 features trying
> to make sure we understand them and their impact.
> As a result, I am sending out several messages, one
> for each feature, with various comments in an attempt
> to restart conversation on some of these.
> 
> Has there been any discussion of this beyond
> http://lists.oasis-open.org/archives/dita/200703/msg00015.html
> 
> I'm not sure I understand what processing expectations
> there are here.  I gather almost any element can have
> a <collate-as> child element and that this is supposed
> to have some processing expectations.  (Don't know what
> happens if there are more than one <collate-as> children,
> or if a non-<collate-as> child has, in turn, a <collate-as>
> child, and there are probably other such things to consider.)
> 
> But then what is supposed to happen?  I know what it means
> to have index-sort-as, because I know what it means to create
> and sort an index.  But when you put a <collate-as> element
> in a title (as in the use case), how am I supposed to know
> what this means?  There is no sort processing usually associated
> with titles.  And, in the use case, I see the title is a child
> of a glossentry, and I'm betting there is some expectation that
> the entire glossary is supposed to have its glossentry children
> sorted based on the <collate-as> child element of the title
> child within the glossentry.  But where in the DITA spec is any
> of this processing discussed?
> 
> I see mention of sorting tables and lists, but where in the DITA
> spec is sorting of table and lists discussed?
> 
> By the way, the time required for this is greatly understated.
> I could see spending weeks trying to document this after having
> spent weeks trying to understand all the bits and pieces and
> special cases involved.
> 
> paul