12035 Generic collation element

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

>