[tei-council] facsKey agayne

[James Cummings]

Lou wrote:
> 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".

If we are planning to move this to things like @ref and @target 
and other xsd:anyURI attributes, then I think it should be 
documented. I don't think we need to specify the method of 
documentation, just that it should be documented. I would propose 
that there should be a container element in the header somewhere 
(perhaps there is a suitable location already?) as the location 
for describing the method for resolving or nature of these 
pseudo-protocols.

I want to suggest a requirement that any pseudo-protocol name 
should be the @xml:id of this description. This does have the, I 
think beneficial, side-effect of limiting the values of these 
pseudo-protocols to be an XML QName.... thus it couldn't have 
spaces so you could not do: facs="john walsh:abc123" but could 
do: facs="john_walsh:abc123" with a <protocolDecl 
xml:id="john_walsh">This is just something John made 
up.</protocolDecl>.

I think that it should be an error (schematron enforced?) if the 
protocol is not so defined unless it is one of the official IANA 
registered protocol schemes. (see 
http://en.wikipedia.org/wiki/URI_scheme#Official_IANA-registered_schemes 
... though there are many that are unofficial which I had assumed 
were official.)

That seems to me to tread the balance between proper 
documentation and freedom/flexibility.

-james