OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message


Subject: #12035 Generic collation element

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
