[tei-council] datatypes again: make data.key a URI

[James Cummings]

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 
> URI.

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.

-James