#396 <ptr>


The discussion of April 2012 regarding <ptr> included Lou's "we will certainly consider these revisions" and there were a few suggestions that the Guidelines might be too focused on how <ptr> is used in marking up the Guidelines themselves.

But the issue never made it into Sourceforge. So here it is.

I stand by the position that Dan O'Donnell summarized better than I did: "ptr should not be used when the textual stream depends on ptr being resolved to a particular representation (or at all)." That is, if <ptr> is just a pointer, it should merely point. If the <ptr> can't be simply ignored without corrupting the textual stream, then (at least as currently documented) it should not be used. Maybe <ref> with a @cRef, or maybe some new element, maybe an <include> with a processing directive that could be project-specific such as "everything", "title", "figureNo." -- but <ptr> isn't right, even if that's how the Guidelines are currently marked up.

(By the way, I have seen <ptr> as a straight-up include instruction. It just pointed to external XML that was meant to be read in situ.)

Really, I think <ptr> is now just a generic wrapper for @target. "Oh, I need to point -- to signal a link, a hyperlink, an inclusion of a label, inclusion of a block of XML, whatever -- like @target does, but that's an attribute and I need an element, So I'll use <ptr>."

In the discussion thread, my suggested options appeared at http://listserv.brown.edu/archives/cgi-bin/wa?A2=TEI-L;yjB6%2Fw;201204020828240700.


  • Lou Burnard

    Lou Burnard - 2012-12-29

    In the discussion referred to you proposed the following options:
    a) Make the semantics of <ptr> project-specific and then just be consistent.
    b)Add a flag to <ptr> that indicates which meaning is intended.
    c) Create some third element <point-follow-retrieve-and-include>.
    d) Adopt the convention that an empty <ref /> means what is referred to is integral to the text.

    (a) is more or less what we currently do
    (b) ptr already has @type which is available for this purpose
    (c) isn't that what xi:include is for?
    (d) the notion of "integral to the text" needs more specification before i can comment on this, but I agree that there is a degree of redundancy in our current practice since <ptr target="#foo"/> and <ref target="#foo"/> should be treated exactly the same.

    FWIW, my understanding is that a "link" is a document feature, like a proper name, or a quotation. It can be represented in your encoded version in a way which approximates more or less to the original source, just like a quotation. You might want to say "it's a link and I don't care how it was represented in the original sjuce" (use <ptr>); you might wan t to say "It's a link, and I want to preserve how it appeared in the original source" (use <ref>). In either case you might want to supply some way of indicating the target of the link (that;s whatr @target does).

  • James Cummings

    James Cummings - 2013-01-08
    • milestone: --> RED
    • assigned_to: nobody --> hcayless
  • James Cummings

    James Cummings - 2013-01-08

    Assigning to hcayless to discuss with council; setting as group RED for now since will need significant further clarification and discussion before proceeding.

  • BODARD Gabriel

    BODARD Gabriel - 2013-06-19

    Re point (c) above: <point-follow-and-include> might not be quite the same in functionality (much less semantics) as <xi:include>. When I use <ptr/> inside <bibl>, for example, I don't mean, "Go and find the <bibl[Struct]> element to which this points and transclude it here in full", I mean, "Serialize some aspects of/representation of the bibliographic entry to which this points alongside the <citedRange> that's in here." But semantically I mean, this citedRange refers to that bibliographical entry over there; do with it what you will.

    (Or maybe I should just be using @corresp for that? :-p )

  • Syd Bauman

    Syd Bauman - 2013-11-13
    • status: open --> closed-invalid
    • Priority: 5 --> 1(low)
  • Syd Bauman

    Syd Bauman - 2013-11-13

    Processing issue seems adequately addressed in comments above.