[tei-council] facsKey agayne

James Cummings James.Cummings at oucs.ox.ac.uk
Tue Feb 9 12:53:09 EST 2010

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 

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 

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


More information about the tei-council mailing list