- From: Martin Duerst <duerst@w3.org>
- Date: Sun, 05 Sep 2004 09:04:29 +0900
- To: "Hammond, Tony" <T.Hammond@nature.com>, Larry Masinter <LMM@acm.org>, uri@w3.org
- Cc: djz@corp.webtv.net, rpetke@wcom.net, 'Harald Tveit Alvestrand' <harald@alvestrand.no>, Tony Hansen <tony@att.com>, 'Paul Hoffman / IMC' <phoffman@imc.org>
At 16:56 04/09/01 +0100, Hammond, Tony wrote: >Hi: > >I had a few questions - see '@@@' > > > - We have to clearly state that every URI scheme syntax has > > to follow the (generic) URI syntax in that it cannot allow > > URIs that don't fit into the URI syntax. As a very simple > > example, if a foo: scheme would allow "#" as part of the > > URI syntax, it would be out. Similar for misusing "%", and > > a few other things. > >@@@ Not clear that I understand why "#" would not be allowed. According to >2396bis it is a legal URI character introducing a fragment component which >is an optional component of a generic URI. Yes. But URI schemes only describe the part before the "#". Fragment identifiers are independent of URI schemes. In other terms, the syntax that an URI scheme has to define has to be a subset of absolute-URI in rfc2396bis. > > - We also should recommend that any components of the generic > > syntax (e.g. // for top level, / for hierarchy,...) are used > > with the semantics defined in RFC 2396bis. > >@@@ I am also not sure that 2396bis goes so far as to actually require It does not. That's why I used 'recommend' above, not 'require'. >"/" >to be a hierarchical delimiter for a given scheme, but it rather says that >URI schemes that do not want to remain opaque must support hierarchical >processing. (I presume the "data" URI scheme would also support hierarchical >processing.:) I think we will have to work on the details of the wording here, to get it right. > > >I think it's useful if schemes are clear about whether > > >(or under what circumstance) the 'resource' might be > > >something that returns a (body/entity/...?) which has > > >a Media Type, and can be used with fragment identifiers > > >in their conventional definition. > >@@@ What is the media type of a non-dereferenceable URI, as might be minted >in a typical RDF application? This all seems very metaphysical to me. Or >does the media type only come into play if a URI is dereferenced? The RDF spec has some language somewhere that says something like that a fragment id is to be interpreted as if the entity was of type application/rdf+xml in case no entity can be retrieved. That doesn't really mean too much, it just means "if you don't have a media type to figure out what a fragment identifier means, it means whatever it means". Metaphysical if you want to call it that, or practical "nothing known in particular", if you prefer that. In the general case, I think this is quite untread territory. > > >2.3 Demonstrated utility > > > > > >I'd like to suggest that we require something stronger: that new URI > > >schemes have demonstratable, new, long-lived > > >utility: > > > > > > Because URI schemes are a single, global namespace, the > > > unrestricted registration of many new URI schemes can > > > clutter implementation space, and possibly lead to > > > contention for "short names". For this reason, new > > > URI schemes should have a clear utility to the broad > > > Internet community, and provide some means of identifying > > > resources that is not already available with previously > > > registered URI schemes. > > > > > >Perhaps this is controversial :) > > > > It seems to go into the opposite direction of what was > > discussed at the BOF, namely to relax the rules. But I guess > > this could work out by saying that the above is desirable, > > and there should be potential for it, rather than having it > > as a hard-and-fast rule. > >@@@ Would have to agree with this last comment. I see no problem with >cluttering of implementation space. An implementation should be able to >detect a string being used within a URI context, parse it out to see that it >conforms to the generic URI syntax, and then discover whether it has any >rules to dereference such a URI. Of course, most implementations do not >recognize generic URIs but only specific schemes which are hard coded into >them. I am not a little sceptical of there being some kind of gold rush on >URI scheme names. Do you mean "not even a little sceptical", or "not just a little, but a lot sceptical"? Or in other words, do you think we will have a gold rush, or we won't? Regards, Martin.
Received on Sunday, 5 September 2004 00:05:26 UTC