[tei-council] more on facsKey debate

Sebastian Rahtz sebastian.rahtz at oucs.ox.ac.uk
Tue Feb 9 16:47:42 EST 2010

I asked around at work. The message below is a useful confirmation that
we're not barking mad.

I also see a useful quote from http://www.ietf.org/rfc/rfc3986.txt:

"A common misunderstanding of URIs is that they are only used to refer
   to accessible resources.  The URI itself only provides
   identification; access to the resource is neither guaranteed nor
   implied by the presence of a URI.  Instead, any operation associated
   with a URI reference is defined by the protocol element, data format
   attribute, or natural language text in which it appears."

Begin forwarded message:

> First we should remember that the "protocol" of a URI is not a protocol, 
> it is a schema. In many cases it happens to be a protocol too, but that 
> is coincidence rather than design. In fact, in an URL it can be an 
> indicator of resource type.
> Next we need to ask how is the attribute facs defined? Do your docs say 
> that it contains an URI, URL or URN?
> If an URL then this is, a little evil since URLs are intended to refer 
> to the location of a resource. Providing a locator that is not easily 
> dereferenced is a problem for clients. However, strictly speaking it is 
> legal.
> I'll skip URNs as you say you don't want to use them.
> So that leaves us with URIs. In theory all schemes should be registered 
> with IANA, but in practice unregistered schemes are used. As with URLs 
> the fact that processors don't know how to work with unregistered 
> schemes is a minor hinderence, a well behaved client will fail 
> gracefully. However, they need to know how to.
> So, as far as issue a) is concerned, I would suggest you (re)define 
> @facs as an URI and allow the use of unregistered schemas. Since URLs 
> and URNs are subsets of URIs there would be no backward compatibility 
> issues. By defining @facs as a URI you are sending a clear signal to 
> client maintainers that they may receive something that does not 
> necessarily provide a location for the resource.
> With respect to b) URIs, by definition, are not permanent identifiers 
> nor are they necessarily unique. For example "../hello.png" is "only 
> unique in the processing domain, it is not in any sense a permanent 
> identifier".
> So, in summary:
> Ensure @facs is defined as a URI and encourage people to use world 
> unique identifiers and I believe it is not evil.

Sebastian Rahtz      
Information Manager, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

Sólo le pido a Dios
que el futuro no me sea indiferente

More information about the tei-council mailing list