Menu

#211 global @facsKey

AMBER
closed
nobody
5
2010-04-29
2009-12-22
No

I request the addition of an @facsKey element. The datatype of @facs 1–∞ occurrences of data.pointer. The proposed @facsKey element would be of datatype data.key and provide an externally-defined means of identifying the facsimile entity (or entities) being referenced, using a coded value of some kind.

Such an attribute would be useful, for instance, in referencing facsimile images and derivatives described in an external METS file or database, which may provide a useful alternative or complement to the functionality of the TEI <facsimile> element.

Discussion

  • Lou Burnard

    Lou Burnard - 2010-01-15
    • milestone: --> AMBER
     
  • Lou Burnard

    Lou Burnard - 2010-01-15

    See discussion on tei-l 2009-12-22 to 23rd or so.

    The problem seems to be that the global @facs is defined as a pointer (like @ref), and for many real life applications it would be much more useful to define it as a "magic token" (like @key) from which an app will generate whatever it needs to locate the intended image. We could either take the suggestion here and add a differently named attribute or redefine the datatype of @facs (and add a new URI-valued attribute)

    preferences?

     
  • Kevin Hawkins

    Kevin Hawkins - 2010-01-16

    I don't follow this: "or redefine the datatype of @facs (and add a new URI-valued attribute)". Do you mean "or redefine the datatype of @facs (to be of type data.pointer)"?

     
  • Syd Bauman

    Syd Bauman - 2010-01-24

    I think John's request is valid, and Lou's analysis is right on target. It's too bad we didn't think of this earlier, and have a facsRef= and facsKey=. But changing the datatype of facs= now seems like a bad idea: it will likely cause confusion even if it doesn't happen to actually break anyone's software. So I prefer either John's suggestion (new, differently named attribute, e.g. facsKey= as a “magic token”), or dropping facs= altogether and replacing it with two new, differently named attributes, one for a “magic token” and one for a URI (e.g., facsKey= and facsRef=).

    Yes, I know dropping facs= breaks existing documents, but it's not confusing — the fix is obvious, clear, and easy to supply a stylesheet for.

     
  • Sebastian Rahtz

    Sebastian Rahtz - 2010-02-07

    I don't think the consistency gained by the renaming of @facs to @facsRef is worth the trouble it would caused. So I'd go reluctantly along with the extra @facsKey attribute; though a) I don't much like the name, b) it'll mean a Schematron rule to say that the two of them are mutually exclusive, and c) it's unfriendly to have to add another global attribute. On the whole, I wish John hadn't asked for it :-}

     
  • Sebastian Rahtz

    Sebastian Rahtz - 2010-03-03

    I think the request can be catered for by more creative use of the URI scheme. There are three possibilities
    a) actually use URNs in their full raging glory, as in
    <p facs="urn:www.ox.ac.uk:P45">Hello world</p>

    b) invent an arbitrary schema, which means something to you:

    <p facs="oxpics:P45">Hello world</p>

    c) use "tag URIs" as documented in RFC 4151 (http://www.ietf.org/rfc/rfc4151.txt)

    <p facs="tag:indiana.edu:P45:>Hello world</p>

    None of these is quite ideal, but then neither is @facsKey.

    I humbly submit that the existing @facs with its URI semantics is sufficient unto the day thereof.

     
  • Lou Burnard

    Lou Burnard - 2010-03-03

    The observation that we are not using the URI syntax to the full is so cool you could call it Nanook. It suggests that we could also get rid of all those pesky @key attributes, and have just one way to do things.

     
  • John A. Walsh

    John A. Walsh - 2010-03-04

    I can certainly live with one of the suggestions proposed by Sebastian, as long as none of them are the URN equivalent of tag abuse. Sebastian's option b seems easiest, but is it really acceptable to "invent an arbitrary schema"? Is there a notion of a "private use" schema, like the private use code points of Unicode?

     
  • Lou Burnard

    Lou Burnard - 2010-04-29

    The @facs attribute currently permits any of the three so no action is needed. Council will discuss recommendations for use of URIs in general.

     
  • Lou Burnard

    Lou Burnard - 2010-04-29
    • status: open --> closed
     
  • Syd Bauman

    Syd Bauman - 2010-04-29

    My instinct, John, without having read the RFCs carefully yet, is that
    1) You are permitted to create a scheme of your own, but you can't guarantee that it is unique unless you register it, which is a big pain
    2) If you are inventing a scheme that is not supposed to be de-referenced, I would not be surprised if you can't register it, as there is already a scheme for such things (tag:, Sebastian's (c))

    Although it is a bit unweildy, the tag: URI scheme seems to do exactly what we want:

    <pb facs="tag:wwp.brown.edu,2010:/exhibits/images/f7p12" n="12"/>

    However, there is a problem. There are 2 places in the TEI Guidelines where use of this mechanism makes sense, but the attribute semantics preclude it:
    url= of <graphic>
    and
    url= of <moduleRef>

    (I realize that this is above and beyond the original feature request, which the tag: scheme does solve)

     
  • Kevin Hawkins

    Kevin Hawkins - 2011-11-28

    Discussion of use of URIs more generally is happening at FR 3437509 and recently on tei-council.