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]