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

[Alan Houser <arh@groupwellesley.com>]

The message below is from Yas Etessam in response to Paul Grosso. Yas' email to the list is bouncing, so I'm forwarding this for her to maintain the timely exchange.

-Alan

-----Original Message-----
From: Yas Etessam 
Sent: Thursday, August 02, 2007 1:10 PM
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