Re: TAG Issue proposal: URIs should not be hierarchical

Le 28 août 06 à 10:21, Fernando Franco a écrit :
> Today URIs can be something like
> http://example.org/something/something/something
> I reckon they should only be
> http://example.org/something

Why do you think this is hierarchical? Or mor exactly which kind of  
hierarchy are you thinking of?


First, It seems the issue described above is about "HTTP URIs" and  
not URIs.

Let's take an example

	http://example.org/life/is/beautiful/

can perfectly be equivalent to

	http://example.org/is/beautiful/life/

or even
	http://example/pathhasnomeaning/

How? for example in Apache

RewriteEngine On
RewriteRule ^life/is/beautiful(.*) /is/beautiful/life$1

RewriteRule ^life/is/beautiful(.*) /lifehasnomeaning$1


The fact that you can read a URI and that you can put slash into it  
doesn't have more meaning than anything else.

> Please see:
> http://lists.w3.org/Archives/Public/www-tag/2006Aug/0066.html
> (which contains the true rationale)
>
> I did check the specs, btw, and a lot of them mention the  
> hierarchical thing
> in no uncertain terms.
>
> This contains an extra paragraph about hierarchies-classifications  
> and their
> problems in xml:
> http://lists.w3.org/Archives/Public/www-tag/2006Aug/0086.html


It is explained in "1.2.3.  Hierarchical Identifiers". The hierarchy  
in HTTP URIs is not the "sequences of slashes" but the sequence of  
parts.

then

[[[
    The following are two example URIs and their component parts:

          foo://example.com:8042/over/there?name=ferret#nose
          \_/   \______________/\_________/ \_________/ \__/
           |           |            |            |        |
        scheme     authority       path        query   fragment
           |   _____________________|__
          / \ /                        \
          urn:example:animal:ferret:nose

]]] - http://www.ietf.org/rfc/rfc3986.txt

The hierarchy is

      scheme
     authority
       path
      query
    fragment

Then you could argue that the hierarchy is explicitly described in  
RFC 3986,

[[[
The path segments "." and "..", also known as dot-segments, are  
defined for relative reference within the path name hierarchy. They  
are intended for use at the beginning of a relative-path reference  
(Section 4.2) to indicate relative position within the hierarchical  
tree of names. This is similar to their role within some operating  
systems' file directory structures to indicate the current directory  
and parent directory, respectively. However, unlike in a file system,  
these dot-segments are only interpreted within the URI path hierarchy  
and are removed as part of the resolution process (Section 5.2).
]]] -- http://www.ietf.org/rfc/rfc3986.txt
        Mon, 24 Jan 2005 20:28:56 GMT

The slash in a path gives possibility to map a "hierarchical tree of  
names", it is a convenience it doesn't have a specific meaning more  
than the one of organizing information space for the URIs owner.

For example, an analogy with alphabet, there is no specific meaning  
of having

	A, B, C, D, E, F, etc.

Though it's quite practical to create a dictionary of words, and be  
able to access the information. The hierarchy of the alphabet has no  
specific meaning, it doesn't follow a rule of an encyclopedic  
organization of the world.

Chinese characters will have different classification orders to make  
them easier to find by number of strokes or by radical characters.  
Again it has no meaning, it is just a convenience.

the ".", ".." and "/" is a mechanism to "navigate" an information  
space that the URIs owner has chosen to organize.


At least the way I interpret it.




-- 
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager, QA Activity Lead
   QA Weblog - http://www.w3.org/QA/
      *** Be Strict To Be Cool ***

Received on Monday, 28 August 2006 03:13:12 UTC