detailed critique?

Hi Jim,

I saw your posting on the URI list last week, but didn't reply in favour of 
waiting  for your detailed comments; I've attached further thoughts below.

> available.  I will try to get a detailed critique of what I believe should 
> change in Roy's draft in the next day or two.

I'm kind of wondering what the expected next step is at this point?

Hope all is well.

Leslie.


Reply comments...

I think there is an agreement in principle that All Will Be Better with a 
unified syntax.  I'm cautious about whether we all have a shared view of what 
that means.

On Mon, 9 Feb 1998, Jim Gettys wrote:
> View of URI syntax as a Class Hierarchy
> ---------------------------------------
> 
> 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.

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.

> Consequences of URI's Being Embedded in Content
> -----------------------------------------------
> 
> The utility of embedding links into document is certainly now clear to 
> the world.  But the fact that links are internally embedded into many 
> data types (e.g. HTML, XML, Microsoft Word, Adobe PDF, etc.) have 
> consequences.  Note that below I mean "naming authority" to be scheme 
> specific delegatee of part of a name space; for example, the www.w3.org 
> in the URL http://www.w3.org/foo/bar/baz.html. 
> 
>      o If fragment syntax (to the extent of understanding the URI is a 
>      fragment), isn't shared between two schemes, (e.g. ``<a 
>      href=``#foo''>''), you can't move individual completely self 
>      referential documents between schemes without rewriting the 
>      document.  In the Web, the fragment syntax is a property of the 
>      media type, and evaluted by the client.
>      o If fragment syntax is not shared between different media types of 
>      the same capability (e.g. HTML, XML, Word, or image types 
>      such as GIF, JPEG, PNG)  then you can't have a URI reference 
>      that can evolve to superior media types as they become available, 
>      or even likely work properly today with content negotiation.
>      o If relative syntax (to the extent of understanding the URI is 
>      relative, and what part of the URI string is relative) isn't shared 
>      between two schemes,  (e.g. ``<a href=``foo''>''), you can't 
>      move sets of documents that are internally self referential between 
>      schemes without rewriting.
>      o If ".." syntax as a path component in relative URI's isn't shared 
>      between schemes, you can't easily have sets of document sets and 
>      refer to them between schemes without rewriting.
[snip]
>      o If query syntax (to the extent of understanding the URI has a 
>      query, and what part of the URI string is the query) isn't shared 
>      between two schemes ( the syntax is a property of the server, 
>      rather than the client).


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.

>      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.

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.

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".  

>      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.

This is also "best current practice", and is entirely relevant to the
Web community.  There probably should be a document outlining these things.

> 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.



----------------------------------------------------------------------------

  "_Be_                                           Leslie Daigle
             where  you                           
                          _are_."                 Bunyip Information Systems
                                                  (514) 875-8611
                      -- ThinkingCat              leslie@bunyip.com
----------------------------------------------------------------------------

Received on Friday, 20 February 1998 18:20:18 UTC