- From: Williams, Stuart (HP Labs, Bristol) <skw@hp.com>
- Date: Tue, 15 Jul 2008 16:15:12 +0000
- To: John Bradley <john.bradley@wingaa.com>, Julian Reschke <julian.reschke@gmx.de>
- CC: Mark Baker <distobj@acm.org>, "Booth, David (HP Software - Boston)" <dbooth@hp.com>, "www-tag@w3.org" <www-tag@w3.org>
- Message-ID: <233101CD2D78D64E8C6691E90030E5C811741A5CE7@GVW1120EXC.americas.hpqcorp.net>
Hello John, > My question around WEBDAV was not really directed at XML but rather the processing by > WEBDAV aware clients of webdav URLs in the http: scheme? > > WEBDAV extended the operators beyond GET and POST, and had a extended web server that > dealt with information encoded in the path. Having had a hand in the metadataInURI-31 finding [1] it started trying to unpick the the simple mantra that... "URI are 'opaque" because it's not that simple. I think of it in terms of three pieces: - Web infrastructure (which is made of things like generic client-side/server-side libraries eg. libwww and proxys); - clients (specifically the pieces of a client that 'above' generic libraries or their moral equivalent); - origin servers (which you might also regards as infrastructure); One idea wrt to opacity is that when defining a web language or format that has a URI shaped slot in it, that slot should be capable of taking any kind of URI. To do otherwise restricts the potential utility of that format. I see the client-side libraries, or their moral equivalent, as part of the web infrastructure - they clearly have to be able to parse a URI into its component parts. The URI scheme is, in most cases, a major determininant of how an access is performed using that URI (in some cases it would simply be passed off to a proxy regardless). The fragment portion is alos separated from what goes on the wire... basic point is that there is a level of generic processing here that parses a URI into its major components. In that sense, some might argue that opacity gets broken... however, the finding [1] was is more forgiving. You're 'allowed' to parse things in accordance with the relevant specs: Generic URI-> Scheme and other URI components; Scheme -> scheme specific specs etc. It also leaves space for an authority to state the rules of the substructure of some URI space delegated to them: eg. documentation of query parameters (for humans or machines (in the form of forms)) and at least in principle URI path substructure. At the time, there really was no way other than narrative for a delegated authority to do the latter, more recently URI Templates and perhaps restful WSDL/API documentation seem to be filling some of the gap - at least in terms of writing down the patterns. That said, there is also a note of warning about the stability of such patterns over time. Sites do get re-arranged, web api's change.Deeply programming knowledge of URI structure in into backed client code (as opposed to contemporaneously loaded client side scripts) is a fragile thing to do. As for origin servers, their own URI (ie. the ones which they serve) are not opaque to them at all. Basically, where I think that we tried to leave it was: 1) machines (clients) shouldn't guess, they can pick their way through specifications/stds; authorities may have ways to tell you the same of the URI space they administer with varying commitments to the stability of that info - use with care (if you must); 2) humans can guess, that eg. http://uk.weather.com/weather/today-Bristol-UKXX0025 has something to say about today's weather forecast in the vicinity of Bristol, UK - but be prepared for ocassional surprises. IIRC the WebDav versioning spec. (when I read it sometime ago) is completely not prescriptive about the organisation of URI space on a WebDav server - the relevant spec. leaves it completely open to the server how it organises, say, successive versions of a document in URI space - though (IIRC) it does require the use of a distinct method (PROFIND) to get started. Regards Stuart Williams [1] http://www.w3.org/2001/tag/doc/metaDataInURI-31 -- Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England ________________________________ From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf Of John Bradley Sent: 15 July 2008 16:20 To: Julian Reschke Cc: Mark Baker; Booth, David (HP Software - Boston); www-tag@w3.org Subject: Re: Boeing XRI Use Cases On 15-Jul-08, at 2:24 AM, Julian Reschke wrote: John Bradley wrote: ... If there is a document stating how others like webdav were able to navigate this process, perhaps that could be of some help to the XRI-TC. ... WebDAV extends HTTP, and addresses resources through regular HTTP(s) URIs. The "DAV:" URI scheme was only defined for use as an XML namespace name, which was certainly an extremely bad idea in the first place. RFC 4918, which obsoletes RFC 2518, continues to do so only for backwards compatibility (see <http://www.webdav.org/specs/rfc4918.html#rfc.section.21.1>). (That Subversion re-did that mistake with it's (non-registered) "svn:" scheme doesn't help.) BR, Julian Thanks for the information Julian, I don't think it has ever been a goal to use xri: as a XML namespace name. Yes we would be guilty as charged if you look at a XRDS or at places in the XRI 2.0 spec where this occurs. It's a bit of a pride thing, we defined a URI form of an XRI so we used it in our own definitions. It is my belief that there is no place in the spec where xri: is used as a XML namespace name that a URL could not have been used. <XRD version="2.0" xmlns="xri://$xrd*($v*2.0)"> This uses the XRI versioning syntax that we have some attachment to. David Orchard has concerns that this is not a valid URI. That is one question I don't think has been resolved completely. If the scheme were registered is this valid as a URI without further escaping? In my email to David I review the transformations required to go from XRI-Normal form to URI-Normal form. If to make people happy we use the HXRI form it is not the end of the world. It will take 1 month of writing and 6 months of OASIS process to get a revised spec to a vote. The XRI-TC believes that it has done the correct thing with the URI-Normal form. To my knowledge no specific technical fault has been found with it. Yet I at least (the XRI-TC will tell you I don't speak for all of them) am willing to consider abandoning the use of the URI-Normal form. Using http scheme URLS exclusively in XML namespaces is just fine with me. My question around WEBDAV was not really directed at XML but rather the processing by WEBDAV aware clients of webdav URLs in the http: scheme? WEBDAV extended the operators beyond GET and POST, and had a extended web server that dealt with information encoded in the path. We have not proposed new operators to extend the http protocol with HXRI. If xri and webdav and http are to all share the same http: scheme addressing then how are the clients like XDI servers and possibly web browsers going to recognize these URIs? Is there something we can learn from others attempts to fit themselves into the http: scheme? Some people feel that if we conform to http: scheme addressing we must still justify XRI in some way. How have other people met this challenge? I ask about WEBDAV because it would appear to have some of the same issues we will encounter tying to re-use the http: scheme. I will have a look at RFC 2518 to see if it can shine some light on this. Thank you for your input. Regards John Bradley OASIS IDTRUST-SC =jbradley
Received on Tuesday, 15 July 2008 16:17:41 UTC