#405 XPointer schemes may not nest, but see ch. 16

GREEN
open
1(low)
2013-11-13
2012-05-02
No

Please verify:

1. this is XPointer syntax: http://www.w3.org/TR/xptr-framework/#syntax
2. the TEI schemes defined in chapter 16 are meant to be well-behaved XPointer schemes
3. XPointer schemes may be chained, but may not be nested [everything depends on this assumption, so please attack or confirm]
4. In ch. 16, we have examples such as:

a. string-range(element(/1), 84,109)
b. range(xpath1(id(par1)//emph),xpath1(id(par2)//emph))

with TEI-defined schemes containing W3C-defined schemes in (a), and TEI-defined schemes containing third-party-registered schemes in (b).

Discussion

  • Piotr Banski

    Piotr Banski - 2012-05-02

    By way of further explanation: id() is not a scheme but a function, so it can be nested all right.
    I tried to tease apart the two unfortunately homonymous string-range()s here:

    http://wiki.tei-c.org/index.php/XPointer

    I once suggested renaming the TEI's scheme to string-span(), to avoid the ambiguity. Maybe we could still consider that, given that these schemes haven't been used in any other form but as informal shorthand notations?

     
  • Martin Holmes

    Martin Holmes - 2012-05-02

    +100 from me for renaming TEI's string-range to something else (string-span sounds good). This has seriously confused me in the past.

     
  • Piotr Banski

    Piotr Banski - 2012-05-03

    The tricky trick concerning assumption 3 is that syntactically, there is nothing wrong with having something like

    scheme( name1(), something)

    in particular, "name1" can be a name of another scheme, e.g. "xpath1" or "xpointer" (it can also be "a:bc:d", but that's another thing, and not so relevant to the issue at hand).

    So one could say, why, the XPointer Framework doesn't preclude schemes which take other schemes as arguments, so the Guidelines are OK ("what's not explicitly prohibited is permitted").

    To which my answer would be: but the TEI string-range() is defined as

    string-range(fragmentIdentifier, offset [, length]) [16.2.4.5]

    and, on the assumption that "fragmentIdentifier" is an actual datatype returned by barename pointers or XPointer schemes, it implies that you can put any XPointer scheme there.

    Next, the Guidelines say "The other five schemes overlap in functionality with a W3C draft specification known as the XPointer scheme draft, but are individually much simpler." (16.2.4.1). Given that these schemes are defined in such a way that they take the existing XPointer schemes as arguments, I see no increase in simplicity here, quite on the contrary. A scheme that presupposes other schemes as arguments may not be simpler than those individual schemes. Additionally, it involves evaluation of XPointer schemes in contexts where *no* W3C specification expects them (= as arguments to other schemes). No simplicity there at all.

     
  • James Cummings

    James Cummings - 2012-06-29
    • assigned_to: nobody --> rahtz
     
  • Laurent Romary

    Laurent Romary - 2012-06-29

    Just to mention: it would be quite unfortunate to rename string-range() now that ISO MAF has been sent out for editing at ISO central secretariat. This should have been raised within the SOM group when I suggested the syntax introduced in the document.

     
  • Lou Burnard

    Lou Burnard - 2012-09-16
    • milestone: --> 871212
     
  • Lou Burnard

    Lou Burnard - 2012-09-16
    • milestone: 871212 --> 871213
     
  • Lou Burnard

    Lou Burnard - 2012-09-16
    • milestone: 871213 --> 871212
     
  • James Cummings

    James Cummings - 2012-09-21

    Assigning to GB, Incorporate this ticket into the StandOff Markup discussion and report back to Council.

     
  • James Cummings

    James Cummings - 2012-09-21
    • milestone: 871212 --> AMBER
    • assigned_to: rahtz --> gabrielbodard
     
  • James Cummings

    James Cummings - 2012-09-21

    Assigning to GB, Incorporate this ticket into the StandOff Markup discussion and report back to Council.

     
  • Hugh A. Cayless

    Hugh A. Cayless - 2013-04-12

    The draft rewrite of the XPointer section completely does away with the idea of nested XPointers. I'm inclined to push ahead with the completion of that rather than spend time patching broken examples in the existing XPointer section, since (as Gabby points out) to fix the examples now might give the impression that the existing recommendation is viable.

     
  • BODARD Gabriel

    BODARD Gabriel - 2013-06-18
    • assigned_to: BODARD Gabriel --> Hugh A. Cayless
    • Priority: 5 --> 1(low)
     
  • BODARD Gabriel

    BODARD Gabriel - 2013-06-18

    Assigning this ticket to Hugh, who has more control over the XPointer process now that he is on Council. If he feels that there is Council consensus to ignore the existing Pointer schemes in favour of the new proposal (or some other complete revision) he should close this ticket with a comment to that effect.

     
  • Martin Holmes

    Martin Holmes - 2013-11-13

    Council 2013-11-13: While HC works on the broader revision of the XPointer section of the Guidelines, we think we should assign this particular ticket, which appears to be a corrigible error, to SB, who can just make an interim fix if he determines that the Guidelines prose and/or examples are technically wrong.

     
  • Martin Holmes

    Martin Holmes - 2013-11-13
    • assigned_to: Hugh A. Cayless --> Syd Bauman
    • Group: AMBER --> GREEN
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks