RE: [metaDataInURI-31]: Initial draft finding for public review/ comme nt.

Hi Norm,

> -----Original Message-----
> From: Norman Walsh [mailto:Norman.Walsh@sun.com] 
> Sent: 11 July 2003 21:01
> To: www-tag@w3.org

<snip/>

> Yes, it would be nice to get httpRange14 sorted. I think this 
> also has bearing on abstractComponentRefs-37. One of the 
> questions that has to be addressed is whether or not a URI 
> that's intended to identify abstract components can in some 
> sense be known to be more than just a random URI.

Yes (ie. yes that's a question that feels like it needs an answer).

> | [RFC2368 mailto scheme]
> |    "The mailto URL scheme is used to designate the Internet mailing
> |    address of an individual or service."
> 
> So, in looking at this utterance and the others, I think I 
> could apply the principle of being conservative in what you 
> send and liberal about what you receive (I've forgotten the 
> pithy name for that principle, if it has one).

I thinks it's the 'robutsness principle'.

> If you construct a mailto: URI, make sure it identifies an 
> internet mailing address. If you receive a mailto: URI, do 
> not assume that it identifies an internet mailing address.

That has some appeal... I'd be interested in Mark Bakers response to the
*first* of clause. Elsewhere in this thread he's asserted (maybe for example
or maybe for real) that he use (or could use) mailto:distobj@acm.org to
identify himself (ie. the person) - he's also made similar statements about
http://www.markbaker.ca/ (that it identifies Mark the person, not his web
site or a particular page on his website).

> I know that some folks want to make assertions about things 
> based on the scheme of the URI used to identify them (hence 
> httpRange-14), but I remain unconvinced that such axiomatic 
> assertions are a good idea.

Personnally, I can live with the wholly opaque position - it has the hugh
advantage of being very uniform. Picking a URI apart into its 2396(bis)
components puts us at the top of a slippery slope. Client software making
distinctions based on the value of particular components takes us down that
slope. Maybe one can take a couple of careful steps down the slope... maybe
its much safer just to stay at the top.


> | ...and of course the infamous...
> |
> | [RFC2616 http scheme]
> | "3.2.2 http URL
> |
> |    The "http" scheme is used to locate network resources via the HTTP
> |    protocol."
> 
> You know, RFC2616 is about the http *protocol*. 

Well, it also serves as the current registration document for the HTTP URI
scheme.

> That protocol 
> clearly uses (syntactic) information that it derives from 
> http: scheme URIs to locate network resources.
> 
> It's hair splitting, I know, but one might argue that other 
> specifications are free to use http scheme URIs in other 
> ways. For example, to identify cars or people.

Indeed... and there are recent REC's like SOAP1.2 [1,2] that do just that
kind of thing - using URI's to name abstract features and properties. I was
part of the WG when we started doing his. We experimented with plain URIs
and with Qnames, (for compactness) but came back to plain URIs (ie.without
fragments).

> 
>                                         Be seeing you,

Stuart
--
[1] http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#featurereq
[2] http://www.w3.org/TR/soap12-part2/#soapfeatspec

Received on Monday, 14 July 2003 07:58:05 UTC