It's always much easier to frame a question like this in terms of code.
Consider:
<link rel="meta" type="application/xml" title="unAPI"
href="http://example.com/unapi/"; />
<span class="unapi-uri" title="http://www.example.com/%7Eeric#3";></span>
if the spec says that it's a uri, then what ought a client to do with
the encoded ~ and the fragment?
My interpretation of the present spec would be to ask for (note encoding)
http://example.com/unapi/?uri=http%3A%2F%2Fwww.example.com%2F%7Eeric%233
and keep the fragment around in case I get back something where a
fragment id makes sense.
If the spec were to say that the title attribute is an opaque
identifier, I would ask for
http://example.com/unapi/?uri=http%3A%2F%2Fwww.example.com%2F%257Eeric%233
because nothing gives me any guidance on how to determine equivalence
Obviously, this is a case where the URI-ness matters in code.
Eric
My opinion on identifiers vs URIs hasn't changed, please see previous
lengthy discussion on it.
I mean really... what are you going to do if you get something you
recognise as an identifier that doesn't happen to be in the form of a
URI... reject it because the specification says URI only?
No software on the client end is going to validate for URIness, they'll
just pass it through. So for all intents and purposes, URI-ness is
unenforcable anyway and if I have to implement unAPI, you can be certain
that I'll just put in my internal identifier without the meaningless
tag:// prefix.
At no point does URI-ness or lack thereof actually matter. It's just an
opaque character string that uniquely identifies an object to be
returned. If it happens to be globally unique, infinitely persistent
identifier, then congratulations. But until we can start handing out
ISSNs to blogs, this is going to be the trivial minority of cases.
In the mean time, the rest of the world has OAI, SRU, OpenSearch and
OpenURL which exist, can perform exactly the same actions as unapi, and
don't require URIs for identifiers. Yet the 'braindead simple' spec
requires them needlessly.
YMWTFV.
Rob
--
Dr Robert Sanderson
Dept of Computer Science, University of Liverpool
Home: http://www.csc.liv.ac.uk/~azaroth/
Cheshire: http://www.cheshire3.org/
_______________________________________________
gcs-pcs-list mailing list
[email protected]
http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list
--
Eric Hellman, Director OCLC Openly
Informatics Division
[EMAIL PROTECTED] 2 Broad St., Suite 208
tel 1-973-509-7800 fax 1-734-468-6216 Bloomfield, NJ 07003
http://www.openly.com/1cate/ 1 Click Access To Everything
_______________________________________________
gcs-pcs-list mailing list
[email protected]
http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list
