[tei-council] facsKey agayne
lou.burnard at oucs.ox.ac.uk
Tue Feb 9 11:43:55 EST 2010
Martin Holmes wrote:
> Sebastian Rahtz wrote:
>> On 9 Feb 2010, at 15:40, James Cummings wrote:
>>> I think someone should post a summary of the issue to TEI-L for
>>> wider discussion.
>> I was waiting for more thoughts; I dont want to look too stupid on TEI-L.
>> ("hi" to all those people reading this list via Google anyway….)
>>> Would this also mean that other places we have say a @ref and a
>>> @key that we might deprecate @key in favour of optionally using
>>> @ref in this manner as well?
> I really like this idea in principle. IIRC, there isn't yet a formal
> method of deprecating an element or attribute, though, is there?
We do it in the prose. There is a long standing ticket saying we should
have a more formal method of doing that in an ODD, but it's in the heap
of things that would have been discussed at our ODD Workshop if we'd
been funded, chiz chiz.
> We also need to think about @cRef here. I've used that on occasion, and
> have been caught (by Syd, naturally) failing to supply "a canonical
> reference from a scheme defined in a refsDecl element in the TEI
> header", as I'm supposed to. If we're encouraging the use of custom
> protocols in @facs and elsewhere, do we also want to encourage or
> require some equivalent documentation of a method for discovering the
> actual destination of the pointer?
I think @cref and @key are really quite different.
@cRef supplies a "canonical reference" for the element carrying it (and
the mapping between that and an XPath is defined in a <refsDecl>). It
specifies a location *in the current document* by definition, so it's
sort of an alternative to @n or @xml:id
@key supplies a "magic token" which some system can use to locate a
resource in situations where a URI is not available or is dispreferred.
It points out to something almost certainly not forming part of the
Yes, it might be a good idea to document somewhere how the process of
locating that something is supposed to be carried out but it's not
likely to be as simple as "follow this xPath". It's more likely to be
"feed this token into this select statement" or "add a .prn at the end
and a wibble at the beginning and feed the result into the CMS".
Personally, I think the TEI does better to leave well alone -- and say
"this is a magic token. do the right thing with it".
More information about the tei-council