Fw: [dita-comment] #12013 Referencing a range of elements

["Rodolfo M. Raya" <rmraya@heartsome.net>]

Forwarding on behalf of Deborah.

================================================

Date: Tue, 07 Aug 2007 11:33:15 +1000
From: Deborah Pickett <debbiep-ditatc@futzle.com>
To: dita-comment@lists.oasis-open.org
Cc: deborah_pickett@moldflow.com
Subject: [dita-comment] #12013 Referencing a range of elements


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?



This publicly archived list offers a means to provide input to the
OASIS Darwin Information Typing Architecture (DITA) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: dita-comment-subscribe@lists.oasis-open.org
Unsubscribe: dita-comment-unsubscribe@lists.oasis-open.org
List help: dita-comment-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/dita-comment/
Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Committee:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dita



-- 
The information in this e-mail is intended strictly for the addressee,
without prejudices, as a confidential document. Should it reach you,
not being the addressee, it is not to be made accessible to any other
unauthorised person or copied, distributed or disclosed to any other
third party as this would constitute an unlawful act under certain
circumstances, unless prior approval is given for its transmission. The
content of this e-mail is solely that of the sender and not necessarily
that of Heartsome.