#12035 Generic collation element

[Deborah_Pickett@moldflow.com]

I'm packaging up an off-list discussion
here for TC input.  The discussion is about the generic collation
element proposal, which is intended to extend the <index-sort-as>
idea to other elements.

I posted a new version of the proposal,
using the new template, to http://www.oasis-open.org/committees/document.php?document_id=24536&wg_abbrev=dita

Then Alan got this message from Don:

-----
Don Day wrote:
> I am going to leave off #12035 for today. The description lists two
things
> that have not happened yet:
>
>  - "Propose split - topic collation for 1.2, further for
1.3" -- we never
> got an updated version showing this split
>  - It also says that it depends on 12008, Erik's constraints
proposal,
> which hasn't come up yet.
>
> So you might work with Erik and Deborah on getting those dependencies
in
> place before we put this on the agenda.
>

-----
Alan's response:
> Thanks for catching these issues.

> I'm having a bit of trouble getting my head around both of these issues.
> I don't recall the history of the proposed split. From a use case
> scenario, I'm not sure what topic collation alone would provide. Most
of 
> the value of this proposal is the ability to specify collation order
for 
> block-level elements.

> I'm also unclear about the dependency on Erik's constraints proposal,
> although I haven't fully digested Erik's proposal yet. Since Deborah
> raised the constraint herself, I'm sure it is valid.

> I've copied Deborah to get her insights into these issues.

-----
Then I said:
Now that Don mentions it, I do recall
that there was something about the proposal being only for (topic, likely
glossentry) titles for 1.2, but I can't for the life of me remember why.

The dependency on #12008 is a mild one; it's there just to stop <collate-as>
turning up as a potential child element of every other element that includes
<data>, something which users apparently don't like.

If those two preceding paragraphs are supposed to be killing the same bird
then there's a mismatch on how we think #12035 is to be implemented.  If
it's by specializing <data> then there's no need to restrict the
proposal to doing topic titles, since you get the rest for free anyway.
 If it's by adding <collate-as> to the content model of <title>
then there's no way to make #12035 a domain specialization that users can
choose to leave out of their shells. 

-----
To which Alan replied:

Another question I would have brought up during the TC
call -- are there strong reasons for making this a child element instead
of an attribute? I'm generally a fan of "if it's rendered, it should
be an element; if it's not, it should be an attribute value." Of course,
there are exceptions to this guideline.

-----

That last bit I can answer: attribute values get munged
in XML: multiple spaces get compressed into one, newlines become spaces.
 Collations might conceivably care about such things.  Having
it as a child element makes some potentially useful things possible: conref;
having a different xml:lang than its parent; containing markup like <tm>.

But I don't recall the reasoning that led to making the
proposal use <collate-as> only for topic titles at first, even though
I think I agreed with it at the time.  I also can't find any reference
to it in archived meeting minutes.

-- 
Deborah Pickett
Deborah_Pickett@moldflow.com