Opacity (was RE: Boeing XRI Use Cases)

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