- From: David Beech <dbeech@us.oracle.com>
- Date: Mon, 27 Dec 1999 20:39:56 -0800
- To: www-xml-linking-comments@w3.org
On behalf of our AC rep Jim Trezzo (who is on vacation), I am submitting the following Oracle comments on ranges in XPointer. Thanks, David ============================================================ 1. The premise that a selection of a series of characters or strings on an output tree can be referenced back to the source tree for the generation of an Xpointer Range is flawed if the output tree has had any but the simplest of transformations applied to it via XSLT. In fact, since the stylesheet can add new elements itself, there may not even be an input tree element to reference to. After discussing this functionality with our development group, the conclusion is that there is no way to implement XPointer Ranges where the reference is to anything but the output tree itself. Non-range forms of XPointer have many uses independent of output trees, but the range form seems to be special in that its most obvious use case is dependent on the viability of inverse transformation from output to input tree. 2. The concept of range, especially in the use case being offered, inherently is linked to the presentation of the output tree. This brings into the picture the internalization issues of what defines a selection and the resulting characters. The DOM working group, when faced with a similar problem, elected to define "character" as a 16-bit unit. We see no such definition here, and therefore see this problem unresolved even if ranges were confined to the output tree. 3. XPointer support is a requirement across many of the XML specifications and thus implementations are looking to ease the complexity and amount of code necessary to be compliant without limiting core functionality. The inclusion of ranges adds significant code without a clear requirement beyond the use case which exists only in presentations. XPointer support is required even when there is never going to be human readable output. We would recommend that such narrowly scoped functionality as ranges be in an optional feature considered for version 2 if at all. =================================================================
Received on Monday, 27 December 1999 23:42:53 UTC