Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#211 global @facsKey

AMBER
closed
nobody
5
2010-04-29
2009-12-22
John A. Walsh
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

1 2 > >> (Page 1 of 2)
  • 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.

     
  • 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 :-}

     
  • 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
     
1 2 > >> (Page 1 of 2)