RE: [dita] Groups - DITA Proposed Feature #12013 Referencing a range of elements (conrefrange.html) uploaded

["Yas Etessam" <yas.etessam@justsystems.com>]

Well I'm glad to hear that the proposal is moving into a better
direction.  Thank you for the useful feedback and suggestions.

> With the singleton approach, I suggest we continue with
> "the first element in the source must be the same
> type as the start element of the target range" and
> the rest of the usual conref validation, but we don't
> do any such validation for the target of the conrefend.

Great suggestion.  After all, there's nothing for the conrefend to be
compared with in the singleton model.  I agree that the recursive model
makes much more sense on the singleton model.  


> -----Original Message-----
> From: Grosso, Paul [mailto:pgrosso@ptc.com]
> Sent: Tuesday, September 25, 2007 11:14 AM
> To: dita@lists.oasis-open.org
> Subject: RE: [dita] Groups - DITA Proposed Feature #12013 Referencing
a
> range of elements (conrefrange.html) uploaded
> 
> 
> 
> > -----Original Message-----
> > From: yas.etessam@justsystems.com
> >
> > Document Description:
> > HTML version of DITA Proposed Feature #12013 Referencing a range of
> > elements
> >
> > Download Document:
> >
> http://www.oasis-
> open.org/apps/org/workgroup/dita/download.php/25393/con
> refrange.html
> 
> 
> I still have reservations about this proposal in general,
> but I think the singleton approach makes it more palatable.
> 
> The singleton approach seems to have fewer problems,
> and I see no advantage to the paired approach.  In
> particular, I think recursive conreffing with the
> paired design is problematic--I wouldn't want it to
> work as described in the current proposal where it
> sounds like a start conref can/must point to a start
> conref, etc.  (There is no reason the beginning or
> end--or any of the intermediate siblings--of the
> referenced range couldn't be a pointwise conref.)
> 
> With the singleton approach, I think we would have an
> easier time addressing various possible error cases.
> We might just be able to say something like "if the
> conrefend attribute's target is not found on a
> 'following sibling' (in the XPath sense) of the
> conref attribute's target, that conrefend attribute
> is ignored (with or without an error message), and
> the conref is treated as a usual (pointwise) conref"
> and have that cover all error cases.
> 
> With the singleton approach, I suggest we continue with
> "the first element in the source must be the same
> type as the start element of the target range" and
> the rest of the usual conref validation, but we don't
> do any such validation for the target of the conrefend.
> 
> paul