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

["Grosso, Paul" <pgrosso@ptc.com>]

I wasn't suggesting we should use xpath in place of ids.
In fact, I was worried that, once we started with ids for
ranges, we'd have users want to be able to use fancier
xpaths, and I'm not sure what rationale we'd give for
saying yes to ids and no to fancier xpaths, and I think
xpaths would just exacerbate the problems we have with
this feature already.

There are three hurdles to consider for any new feature:

1.  describing it in the spec in a fashion that is
    unambiguous and easy to follow for implementors
    and users alike;

2.  providing an interface to the feature for users
    that is intuitive, unconfusing, and useful;

3.  defining it as something that is implementable by tools.

If we can solve #1, I am not worried about #3 in this case.

I am more concerned with #1 and #2.  It seems to me that a
casual user of this feature would be more likely to create
an instance of one of the error cases than one of the valid
cases.  In fact, a user could create a valid use of this
range feature, and then via subsequent editing (e.g., adding
a different element in the middle of the range), unwittingly
create an invalid use.  This could be very confusing.

And I have yet to see a concise writeup of just what all 
the valid and error cases are and what to do in the error
cases.  I suspect we could come up with such a writeup,
after several iterations, but I'm not convinced it will be
something the average user would easily understand.

I'm still not convinced the number of times this feature
would be useful outweighs all the possible ways it could
go wrong given that there is an obvious workaround:  just
put in multiple conrefs.  Regarding usability, the easiest 
way to see just what is reused is to have individual conrefs
for each bit being reused.  Ranges effectively hide what is 
actually being reused.

But I'm speaking from my usual minimalist position that I
bring to most spec development in that I'm warning that I
don't think this is a good tradeoff.  I'm not saying this
feature would be a disaster, so I won't lie down in the
road against it.

And it's not ready to vote on until we have defined just
what it is and how it works in all possible cases.

paul


> -----Original Message-----
> From: Yas Etessam [mailto:yas.etessam@justsystems.com] 
> Sent: Thursday, 2007 August 02 15:10
> To: Grosso, Paul; dita@lists.oasis-open.org
> Subject: RE: [dita] Groups - DITA Proposed Feature #12013 
> Referencing a range of elements (ConrefRange.html) uploaded
> 
> Hello Paul,
> 
> Thank you for your insightful input.  In terms of the WIBNI (nice)
> factor, this is a usability feature.  I agree that we need to 
> chip away
> at the issues til the costs-benefit analysis makes sense.  Your point
> about the XPointer failed recommendation is disheartening but we did
> agree to try and tackle this problem in 1.2.  
> 
> 
> Start and end locations need to share a common parent, they need to be
> in the correct order.  To narrow the definition further, the 
> start, end
> and in-between elements must be the same. 
> 
> Just like indexterms ranges, we need to have constraints since there's
> no DTD-based definition of validity when it comes to 
> start/end markers.
> 
> 
> 
> In terms of xpath-like features, thanks for bringing that up.  After
> looking at Michael's original proposal, I also considered xpath.  
> 
> Here's sample markup for a conref range using xpath:
> 
> 
>  <li conref="myfile.xml#mytopic/liapple" 
> range-to="following::li[3]")/>
> 
> 
> Adding XPath as a modifier to conref will still require 
> spelling out the
> constraints.  We'd get the standard addressing format, but 
> the downside
> is that one should not use xpath to select arbitrary nodes 
> (which might
> could be invalid when processors try to pull in the content).
> 
> 
> The only meaningful xpaths for conref ranges would those that 
> selected a
> range of immediate and like siblings.
> 
> Since this is a usability feature, it should be simple and 
> easy.   Using
> XPath as the addressing for conref ranges will make DITA more of a
> standards compliant architecture but is it simpler? 
> 
> Will non-techie users find xpath as intuitive as using conref with
> start/end flags? 
> 
>  <li conref="myfile.xml#mytopic/liapple"  conreftype="start")/>
>  <li conref="myfile.xml#mytopic/lifoobar" conreftype="end"/>
> 
> The other difference is that the xpath range-to addressing is that the
> entire addressing model sits on a single node.  That syntax works best
> on applications that don't physically transclude in the xml.   Both
> leading XML editors can handle either form of transclusion but if
> anybody wants to write DITA by hand, having addressing sit on two node
> has some advantages because you can pull in the content into the XML
> instance.  Again, that is a usability issue.  It is easier to 
> understand
> what is being reused if you can see it. 
> 
> 
> Yas
> 
> 
> 
> 
> -----Original Message-----
> From: Grosso, Paul [mailto:pgrosso@ptc.com] 
> Sent: Tuesday, July 31, 2007 7:23 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@xmetal.com [mailto:yas.etessam@xmetal.com] 
> > Sent: Tuesday, 2007 July 31 1:48
> > To: dita@lists.oasis-open.org
> > Subject: [dita] Groups - DITA Proposed Feature #12013 
> > Referencing a range of elements (ConrefRange.html) uploaded
> > 
> > The document named DITA Proposed Feature #12013 Referencing 
> a range of
> > elements (ConrefRange.html) has been submitted by Ms. Yas 
> > Etessam to the
> > OASIS Darwin Information Typing Architecture (DITA) TC document
> > repository.
> > 
> > Document Description:
> > HTML version of DITA Proposed Feature #12013 Referencing a range of
> > elements
> > 
> > View Document Details:
> > http://www.oasis-open.org/apps/org/workgroup/dita/document.php
> > ?document_id=24823
> > 
> > Download Document:  
> > http://www.oasis-open.org/apps/org/workgroup/dita/download.php
> > /24823/ConrefRange.html
> 
> Although I can see the "would be nice" factor for this proposal,
> it makes me very nervous.  It is basically trying to replicate
> the range proposal for the XPointer xpointer() scheme [1] which
> was turned down by W3C and has never been accepted as a standard.
> 
> If we were to consider this proposal, we would have to add a lot
> of careful wording about which combinations of start and end
> locations are valid and what happens when they are not valid.
> 
> Also, as soon as we add this capability, users are going to wonder
> why we didn't also allow xpath-like capabilities for locating
> the conref target.  In particular, if we accept the reasons why
> this proposal's capabilities "would be nice", I fail to see how
> we can argue that one shouldn't be able to specify a conref target 
> via an xpath.
> 
> Personally, the "nice" factor for this proposal doesn't outweigh
> what I see as the potential issues for me yet.
> 
> paul
> 
> [1] http://www.w3.org/TR/xptr-xpointer/#b2b1b1b3b6b7
>