- From: Williams, Stuart (HP Labs, Bristol) <skw@hp.com>
- Date: Mon, 21 Jul 2008 10:13:47 +0000
- To: "Schleiff, Marty" <marty.schleiff@boeing.com>, John Bradley <john.bradley@wingaa.com>
- CC: "www-tag@w3.org" <www-tag@w3.org>
Hello Marty, > -----Original Message----- > From: Schleiff, Marty [mailto:marty.schleiff@boeing.com] > Sent: 19 July 2008 16:57 > To: Williams, Stuart (HP Labs, Bristol); John Bradley > Cc: www-tag@w3.org > Subject: RE: [XRI] TAG recommendation > > Hi Stuart (& All), > > Stuart said: > > If the answer, which I think you give above, is that you always > > get back a representation of an XRDS document, then despite > > the intent the identifier does not infact refer to the spec it was > > intended to reference. > > Using that same logic (with which I disagree), a PURL would > not in fact refer to a resource that needs a persistent > identifier; rather, a PURL would refer to the returned HTTP redirect. Nope... eg. <http://purl.org/dc/elements/1.1/title> refers to a relation between, typically, works of some kind and their titles. It does not refer to the 302 redirection response (erroneous, in that it should be a 303 see other. 302 suggest that the resource has 'moved' temporarally to an other location - whereas 303 typically refers you to something distinct but related to what you asked for). The wget trace below (below the signature line), follows a chain of redirections and grounds out with a 200 OK respoonse on a retrieval of <http://dublincore.org/2008/01/14/dcelements.rdf> which 'happens' (as intended) to say something useful (at least to RDF processors) about <http://purl.org/dc/elements/1.1/title> amongst other things. In this whole process no webarch:representation of <http://purl.org/dc/elements/1.1/title> is provided. Instead redirection is used to reach a distinct (RDF) description (ie. metadata) with its own distinct URI. > I don't know much about PURLs, but I think of them as > "abstract" identifiers because there's a layer of abstraction > between the identifier and the named resource. > > Similar to PURL, XRIs are "abstract" identifiers. XRI > resolution NEVER directly returns the named resource; rather, > resolution returns an XRDS describing how to interact with > the named resource. Ok... so if someone does an http GET operatation on (allow me my ficticious XRI - correct it or improve it to be more in line with XRI intent): http://xri.net/@oasis*specs*os*xri($v2.0)*resolution (or, allowing an XRI scheme, xri://@oasis*specs*os*xri($v2.0)*resolution which modulo IRI->URI conversion can be placed on a HTTP request line). What direct[*] HTTP response should I expect? 1) An http 3xx redirection (preferably 303 IMO) to an XRDS resource with a distinct URI? 2) An http 200 response with an [html|pdf|.doc] representation of the specification? 3) An Http 200 response with an application/xrds+xml representation (without a Content-Location: header)? 4) An Http 200 response with an application/xrds+xml representation (with a Content-Location: header and a reference to a distinct resource)? [*] ie. the response to the given request, rather than the final response after the client has followed a one or more 3xx redirections. Does the answer differ between the different forms of XRI resolution (that would be 'bad')? IMO...: *If* the identifier is an identifier for the metadata (rather than an identifier for the subject of the metadata), 1, 3 and 4 are ok. *If* (as intended in this scenario) the identifier is an identifier for a praticular specification, 1 and 2 are ok and 3 and 4 would be very wrong. > When resolving a PURL, if the software is smart enough, it > can automatically process the returned redirect to retrieve > the named resource. What it then retrieves a representation of is named by the target URI in the Location header: which in the something distinct from the orignal referee. > When resolving an XRI, if the software is > smart enough, it can automatically process the returned XRDS > to retrieve the named resource. And, if the software is smart > enough, it can automatically process the returned XRDS to > interact with the named resource in other ways defined by the > service points in the XRDS. > > BTW, I hope to leave for a week of vacation (as soon as we > can finish packing). So please don't misinterpret a lack of > email from me as a of lack of interest. > > Marty.Schleiff@boeing.com; CISSP > Associate Technical Fellow - Cyber Identity Specialist > Information Security - Technical Controls > (206) 679-5933 Stuart -- Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England $ wget --debug http://purl.org/dc/elements/1.1/title DEBUG output created by Wget 1.11.3 on cygwin. --2008-07-21 10:22:42-- http://purl.org/dc/elements/1.1/title ---request begin--- GET http://purl.org/dc/elements/1.1/title HTTP/1.0 User-Agent: Wget/1.11.3 Accept: */* Host: purl.org ---request end--- Proxy request sent, awaiting response... ---response begin--- HTTP/1.1 302 Found Date: Mon, 21 Jul 2008 09:23:22 GMT Server: Apache/1.3.29 Location: http://dublincore.org/2008/01/14/dcelements.rdf#title Content-Type: text/html; charset=iso-8859-1 Connection: close ---response end--- 302 Found Location: http://dublincore.org/2008/01/14/dcelements.rdf#title [following] Closed fd 3 --2008-07-21 10:22:44-- http://dublincore.org/2008/01/14/dcelements.rdf ---request begin--- GET http://dublincore.org/2008/01/14/dcelements.rdf HTTP/1.0 User-Agent: Wget/1.11.3 Accept: */* Host: dublincore.org ---request end--- Proxy request sent, awaiting response... ---response begin--- HTTP/1.1 200 OK Date: Tue, 15 Jul 2008 14:07:59 GMT Server: Apache/1.3.28 (Unix) mod_jk/1.1.0 Last-Modified: Sun, 13 Jan 2008 21:49:30 GMT ETag: "790116-449c-478a876a" Accept-Ranges: bytes Content-Type: application/rdf+xml Content-length: 17564 Connection: close Age: 501321 ---response end--- 200 OK Length: 17564 (17K) [application/rdf+xml] Saving to: `dcelements.rdf' Closed fd 3 2008-07-21 10:22:45 (856 KB/s) - `dcelements.rdf' saved [17564/17564]
Received on Monday, 21 July 2008 10:15:54 UTC