#12013 Referencing a range of elements

[Deborah Pickett <debbiep-ditatc@futzle.com>]

Hi all,

I'm sick at home and so can't send email from my TC-registered address.
 But I wanted to get my comments on #12013 (Referencing a range of
elements) out there before the next TC call.  Can someone who isn't
asleep at the time please adopt these?

The proposal doesn't speak of what happens when filtering removes one or
both ends of the range.  Is this invalid?  Or is it valid, with the
intervening unfiltered elements remaining?  Is it still valid if all
elements are filtered out?

The proposal doesn't speak of what happens when the range contains text
nodes (because the parent element's content model is mixed).  Valid?
(Perhaps some of the mentions of "element" in the proposal should be
"node".)

What happens when conrefs are chained?  That is, one or both of the
start/end conrefs is to an element that itself is a regular conref
and/or a range conref.  Also, the converse, where a regular conref pulls
an element that happens to be one of a start/end pair?  Does it pull in
the sibling too, and hence the entire range?

What happens when one of the intervening pulled elements is invalid in
the source content model (because of specialization, say)?

I worry about the onus that the author of the reusable content has in
marking the start/end elements *and not messing with them later*.  That
presents a level of coupling that standard conref doesn't have.  In
particular, the common use case of "pull all of the steps in a task,
then add some of my own" has more overhead than it should.  (Think of a
task with only one step (and so only one id on the step).  Others pull
this singleton step with a range conref, with start/end ids the same.  I
then add a second step, and give it a new id.  But all the range conrefs
pulling my steps don't know about this, because they only know of the
one id, of my original step.)  I know that generic XPath is off the
radar (good), but there might be some acceptable middle ground
(something like conref="mytask.xml#taskid/stepsid/*") for common cases
like this.

And now the big one . . . I need to be convinced that the
two-adjacent-element conreftype=start/end markup is better than the
alternative one-element-with-two-conref-attributes markup.  It seems to
me that many of the error conditions mentioned in the proposal would be
impossible if there were only one element doing the conref.  It seems
that the only reason to have two separate elements is so that they can
have different names, to enable pulling of heterogeneous content.  How
common is that use case?  Is it worth complicating the architecture to
accommodate?