RE: A case for GETSRC (or other mechanism to that effect)

A counter argument is that the URL space is demonstrably a
very poor mechanism for searching and classifying information,
thus the introduction of search engines, and protocols like
WebDAV that introduce "properties" that allow you to declare
the information needed for content and keyword based searches
and classification.  That is one of the reasons why
it is preferable for the "source" and the "result" be distinct
resources (with distinct URL's), so that the property mechanism
can be used to locate either the source or the result, depending
on what you are interested in.

Cheers,
Geoff

-----Original Message-----
From: phillip.lindsay@day.com [mailto:phillip.lindsay@day.com]
Sent: Thursday, February 28, 2002 12:25 PM
To: Clemm, Geoff
Cc: w3c-dist-auth@w3c.org; w3c-dist-auth-request@w3.org
Subject: RE: A case for GETSRC (or other mechanism to that effect)




I think a fundamental web architecture issue is being
ignored if we simply look at URL space as a functional
categorization. IMHO, it should be viewed
as a means for classification (as originally intended)
of information, and thus humans should be able to find
resources given an information architecture.  If we assume
a separate/distinct namespace is a requirement, we throw away
the ability to maintain a valuable abstraction.  There
is precedence in presentation of information given
context (.e.g., role) and making DAV:source work would
satisfy this.

Phillip A. Lindsay (phillip.lindsay@day.com)
Principal Architect
Day Software, Inc.



 

                    "Clemm, Geoff"

                    <gclemm@rational.c       To:     w3c-dist-auth@w3c.org

                    om>                      cc:

                    Sent by:                 Subject:     RE: A case for
GETSRC (or other mechanism to that effect)                              
                    w3c-dist-auth-requ

                    est@w3.org

 

 

                    02/28/2002 06:04

                    AM

 

 





As I recall, I was willing to consider the Translate header
or a GETSRC method, if I was the only one who found them
objectionable.  I consider a separate URL space for authoring
a superior approach, since I believe separate URL spaces
are a simpler model, and one that will prove to be more
extensible.  It also is very compatible with common web server
extension mechanisms, which allow you to dispatch to different
modules based on what part of the URL space you are operating in.

So with support from Julian, it no longer is "just me", so I
revert to my natural position, which is against both the
Translate header or a GETSRC method.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Thursday, February 28, 2002 6:12 AM
To: w3c-dist-auth@w3c.org
Subject: RE: A case for GETSRC (or other mechanism to that effect)


>From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
Behalf Of Eric Sedlar
>Sent: Thursday, February 28, 2002 10:43 AM
>To: Peter Raymond; Julian Reschke; w3c-dist-auth@w3c.org
>Subject: RE: A case for GETSRC (or other mechanism to that effect)
>
>
>Comments inlined...

To all: please do not post in HTML. It makes commenting hard, and it breaks
the web archive.

>The proposal would be that Translate: F would only have an effect on the
GET method, and could be either ignored or forbidden on other methods ( one
of the nits that Geoff picked at >at the dinner where we won him over)...

I see. I guess he dind't have to pay his bill either :-)

>There is certainly interoperability for Translate: F, so I don't see why
that needs to go into a separate spec.

It's not defined in RFC2518, so it can't easily be put into it's revision.
If you want to put it in, you'll have to get agreement on lots of issues
(some of which we already discussed). As there currently is *no* technical
documentation about the Translate header, it will be hard to get proper
definitions of it's semantics (saying: "whatever Frontpage does" doesn't
count).

>>- I am also interested in managing more than just websites and may need a
more advanced way of
>>  navigating relationships (perhaps between design documents and the code
that implements them or
>>  between firmware and circuit board designs etc).  This can best be
addressed in another specification.
>The issue of how the executable is generated is a separate question from
getting at the executable content itself (see my reply to Julian's email).
>Regards,

I think you currently consider only a few special use cases. DAV:source was
designed to address a more generic problem. I think it can be fixed, and we
should try this.

Received on Thursday, 28 February 2002 12:34:04 UTC