[tei-council] datatypes again: make data.key a URI
James.Cummings at computing-services.oxford.ac.uk
Tue Nov 1 12:51:35 EST 2005
Lou Burnard wrote:
> Rationale: At present data.key is for "things like database keys" i.e.
> arbitrary strings which are not XML names (like ident), and not
> necessarily pointers (like #ident). A key is a magic string of some sort
> which an external system uses to access some additional information
> associated with the magic string.
> I put it to you, mlud, that this *is* effectively a URI. It is hard to
> imagine any likely scenario in which a database system wouldn't provide
> a URI-encoded way of accessing its contents in this day and age.
What if my key has characters not allowed by URI's (I've not checked
what the restrictions on that since I'm still in Sofia).
> Use case: all naming elements (<rs>, <name> etc.) have a key attribute
> defined as data.key. You *might* want to say <rs key="wibble">Mr
> Bennet</rs> and leave it at that, but it seems at least as likely that
> you will somewhere have a <person xml:id="wibble"> element (not
> necessarily in the same document, but that doesnt matter any more) and
> want to point to it.
> Choices: we could allow for both key= and uri= and say you really ought
> to choose one or the other but not both. we could allow for them as
> alternatives. we could choose just one. My vote is for the last, and for
What if I want to give the <person> element a key to my database but I
want to also give it an xml:id for other purposes?
> Any objections?
I'm not necessarily objecting, just want it explained to me more.
What do we lose if we are only able to have key or xml:id on an element.
More information about the tei-council