Re: detailed critique?

JG:

>> One way of framing the discussion is to view URI syntax is as though it 
>> were an object hierarchy. Then there are a set of methods that can be 
>> applied to a URI string: 
>> 
>>      Scheme(URI);
>>      Fragment(URI),
>>      Relpath(URI), etc.


LD:
>As a largely irrelevant side note,  I'll say that this is one cut on an 
>object-oriented perspective.  I have some trouble with the idea that an 
>"identifier" _is_ the object; it seems to me it should identify the object in 
>question.

In an object-oriented world, the resource is an object, and the resource
identifier is another object. That they're called "methods" instead of "functions"
is just newspeak.

JG:
>> Consequences of URI's Being Embedded in Content
...

LD:
>I believe everything up to here could be agreed on in a uniform syntax
>document.  However, as last this was presented (Roy's document, unedited),
>this was presented in the light of a specific implementation path, not
>an architecture.    What seems to be clearer is that the architecture
>is common across all URI schemes, not necessarily the implementation path
>laid out in that document, and I'd argue that, in the larger scheme of
>things, is what makes it an inadequate document at this time.

Could you please give some examples of where draft-fielding-uri-syntax-02
is "in the light of a specific implementation path" and how that might be
corrected?

JG:
>>      o If / syntax (to the extent of understanding that the URI refers to a 
>>      path relative to the current naming authority) isn't shared, you 
>>      can't have multiple sets of documents easily be moved up or 
>>      down in a relative heirarchy of names and share a common set of 
>>      documents between them, without rewriting the content, shared 
>>      either in that scheme or between schemes.  The best example is a 
>>      site that has a common set of GIF's, JPEG and PNG images, and 
>>      you want to reorganize the site changing the depth of a subtree 
>>      from one depth to another, or from one directory to another 
>>      where the depth isn't the same.

LD:
>The relative interpretation  of "/" has to be shared across URI schemes.
>
>However, saying you should be able to just change the scheme and preserve
>what you are calling the naming authority and the rest of the string
>is, I would argue, _adding_ functionality requirements to what it means
>to be a URI, and I'd argue doesn't belong in a current syntax document.


It isn't _in_ the current syntax document. draft-fielding-uri-syntax just defines
the syntax. It doesn't add any functionality requirements.

>Saying that _if_ you want to be able to provide the same document easily
>through multiple schemes, you should arrange those schemes accordingly
>is more along the lines of a "best current practice".  


Jim's note might become a BCP, then, but we're just talking about why the
current syntax document should remain.

JG:
>>      o If naming authority syntax (e.g. what comes after "//" in most URL 
>>      schemes) and relative path syntax is shared, to the extent of 
>>      understanding that the URI has a naming authority, and what part 
>>      of the URI string is the naming authority vs. path), isn't shared 
>>      between two schemes, you can't share identical name spaces and 
>>      serve them up via different schemes.  (The naming authority 
>>      syntax is a property of the scheme). The fact that HTTP, and FTP 
>>      have the same syntax, for example, has often been exploited by 
>>      sites transitioning from ftp archive service to HTTP archive 
>>      service so that the URL's can be identical between schemes 
>>      except for the scheme; the same content can be served via two 
>>      schemes simultaneously.
>
LD:
>This is also "best current practice", and is entirely relevant to the
>Web community.  There probably should be a document outlining these things.


If we write a separate design rationale document, it doesn't invalidate the design.


>> If the same content cannot be served up under alternate schemes, or moved 
>> to future schemes used in the Web, it will greatly inhibit introduction 
>> of new schemes into the Web.   If Web software cannot be written without 
>> intimate intertwining of knowledge between components, and therefore updating 
>> to introduce new schemes or content types, it will greatly inhibit 
>> introduction of new schemes and software into the Web. 
>
>But, URIs are not just for the Web.  They are used in all Internet
>applications, and there may be schemes that aren't ever intended for
>use within the World Wide Web.


The notion that some schemes are "intended for use within" one application and not
others seems to break the whole concept of "Uniform" for resource identifiers. If
the resource identifier is Uniform, it is Uniform across applications. So I don't think
it is reasonable to posit characteristics of Uniform Resource Identifiers that _don't_
work well with the web. I think this is the crux of the problem. If you want some kind
of resource identifier that is optimized for some application other than the web, don't
call it a URI. Perhaps if we make sure that draft-fielding-uri-syntax clearly indicates
that its scope is "resource identifiers" for "the world wide web", then we might escape
having to repeat this argument.

Regards,

Larry

Received on Friday, 27 February 1998 19:45:34 UTC