#354 use @range instead of abusing @from on <span>

AMBER
closed
Martin Holmes
5
2013-04-11
2012-04-17
Piotr Banski
No

During the discussion of ID: 3496494, I raised an apparently somewhat controversial point with reference to the following statement:

"@from specifies the beginning of the passage being annotated; if not accompanied by a @to attribute, then specifies the entire passage." [1]

[1]: http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-span.html

This statement licenses using the @from attribute as defining a span, rather than identifying the initial point thereof (as an innocent speaker of English would think). It seems to me that this is a rather evil example of attribute abuse, even if sanctified by use (is it?), maybe even more evil for that, because it opens the way to similarly abusing e.g. data.pointer attributes just because they are able to both identify points and identify ranges.

Instead of using the obligatory @from and optional @to, I would like to suggest introducing an obligatory choice: ( @from and @to ) OR @range

The new @range (data.pointer) attribute would do the same job as the @from is now (evilly) licensed to do, except without any abuse of the semantics. As it is now, actually, @from that refers to a series of characters (whatever they are enclosed in) is ambiguous: it may indicate that (1) some word that @from points at is the initial edge of a span, but unfortunately also (2) that the characters of that element *are* the span, and its interpretation would only depend on whether @to is missing. Introducing @range would remove this ambiguity.

Discussion

  • Laurent Romary
    Laurent Romary
    2012-04-20

    I'm not a fan of having two mechanisms here. Would the introduction of @range a good issue for the group on pointers, since @range would definitely need a method to express the corresponding range.

     
  • James Cummings
    James Cummings
    2012-06-29

    • assigned_to: nobody --> martindholmes
     
  • Martin Holmes
    Martin Holmes
    2012-06-29

    I have one slight niggle here: the name @range suggests that there would be two components (start and end of the range). I wonder if, when the intention is to point to a single element by its @xml:id, it would be better to us @target instead?

     
  • Laurent Romary
    Laurent Romary
    2012-06-29

    Well, if you would think that a range is anything from 0 to any number of objects, I would suggest to keep to one mechanism (think of your stylesheet afterwards full of xsl:if's...)

     
  • Martin Holmes
    Martin Holmes
    2012-06-29

    @Laurent: I'm not sure I understand your comment. We have two scenarios:

    <span from="#id1" to="#id5"/>

    <span range="#id7"/>

    I think that the latter would be better expressed as:

    <span target="#id7"/>

    Is that not right?

     
  • Piotr Banski
    Piotr Banski
    2012-06-29

    I've opened another can, haven't I :-)
    I think what I had in mind was close to Martin's interpretation, which I would agree to (i.e., use @target), even if it were to identify a range via an XPointer.

    If I understand Laurent's remark correctly, he is afraid of using multiple URIs as the value of that single attribute, whatever we end up calling it. But IIRC data.pointer is a single anyURI, quite unlike the @targets of old. (right?)

     
  • Martin Holmes
    Martin Holmes
    2012-06-29

    Piotr, you're right, and my suggestion is not very bright. @target would open up the option of multiple data.pointers, which would mean that the use of @from and @to would be obviated.

    On the other hand, with @target, you could do a discontinuous range, whereas @from+@to makes an inclusive range, no? So I would suggest that perhaps @target has a useful side-effect.

     
  • Piotr Banski
    Piotr Banski
    2012-06-29

    Ah, thanks. I mentioned @targets while completely forgetting that @target has absorbed the functionality of holding multiple anyURIs.

    I would think that discontinuous spans should rather be handled at a higher level of abstraction, i.e. at the level of markup rather than attribute values. So, actually, precluding the possibility of using @target to handle discontinuous spans seems quite attractive to me. (You may ask: what if someone gets even lower down on the level of abstractness and uses a single anyURI and tries to use XPointer inside it to indicate disc. spans? My answer would be that, while theoretically possible, we know this to be practically impossible due to the zombieish nature of XPointer). Of course, all of this probably depends on one's definition of "useful" ;-)

    To sum up, I would go back to the initial idea and postulate that we use @range here, defined as a single occurrence of data.pointer. @range would be disjunctive with (@from + @to). The reason for @range over @target is that @target can hold multiple anyURIs.

     
  • Laurent Romary
    Laurent Romary
    2012-06-29

    ... since my flight managed to bring me back to Berlin for a while..
    I don't care so much about which mechanism, but we need a scheme through which single attribute allows you to express all the use case identified her. Boarding again in a new plane... sigh

     
  • Martin Holmes
    Martin Holmes
    2012-06-29

    I'm not sure I understand Piotr's argument completely, but I'd like to suggest that before we discuss any further, we generate a set of realistic use-cases covering the range of uses we envisage for <span>.

     
  • Lou Burnard
    Lou Burnard
    2012-09-16

    I disagree that this is really an abuse. @from always defines the start of a range; in the absence of a @tpo it also defines the end of a range. What's wrong with that ? (Maybe "I'm no longer an innocent speaker of English")

     
  • Lou Burnard
    Lou Burnard
    2012-09-16

    • milestone: --> AMBER
     
  • Piotr Banski
    Piotr Banski
    2012-09-20

    I'm afraid you are anything BUT innocent, Lou, speaker of English or no...

    I still see awkwardness here: it may be customary to omit @from or @to if the other edge of the span is implied (because it is the edge of the entire passage in question). But that would only work on the interpretation that we are looking at the end of a container that immediately dominates the target of @from. To use the example from the Guidelines, slightly modified:

    <div>
    <p xml:id="para2">(The "aftermath" starts here)</p>
    <p xml:id="para3">(The "aftermath" continues here)</p>
    <p xml:id="para4">(The "aftermath" ends in this paragraph)</p>
    <!-- ... -->
    <p xml:id="last_para">....</p>
    </div>
    ...
    <span type="structure" from="#para2">aftermath</span>

    The, I believe, easily derived interpretation of the <span> above is: "from #para2 until the end of the containing <div>". Except I don't think that this is the intended interpretation.

    Instead, I am afraid that the following is currently licensed by the Guidelines:

    <span type="structure" from="#para4">3rd paragraph of the aftermath</span>

    This, in the words of a poet, just sucks... This is where one should use e.g. @target, as Martin suggests (without bothering about the possible (in)sane uses of @target, because silliness is beyond our control anyway).

    So I would now suggest to reword the definition of @from to:

    "specifies the beginning of the passage being annotated; if not accompanied by a @to attribute, then specifies the entire passage from the targeted element to the end of the element that contains it. If a single element should be addressed as the entire span in question, use @target."

    The additional funny thing is that we can theoretically use @from to indicate an inter-character point (rather than a single element). That should get a separate proviso in the definition.

    (I have a feeling that this is not going to be easy...)

     
  • Martin Holmes
    Martin Holmes
    2013-01-08

    • status: open --> closed
     
  • Martin Holmes
    Martin Holmes
    2013-01-08

    Lou confirms this ticket is superceded by his work on <http://purl.org/tei/FR/3518932>. Closing.

     
  • Kevin Hawkins
    Kevin Hawkins
    2013-04-11

    Martin's last comment on this ticket points to this very ticket. Does Lou or Martin remember what was actually superseded by this?