OASIS Open Mailing List Archives  ·  All Lists  ·  dita  ·  2007-08

dita — archive

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]

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


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 >

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]