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 CJ Holmes
> Sent: Friday, March 01, 2002 7:04 PM
> To: w3c-dist-auth@w3c.org
> Subject: RE: A case for GETSRC (or other mechanism to that effect)
>
>
> >    From: CJ Holmes [mailto:cholmes@4d.com]
> >
> >    Well, you can't always "just locate the source".  If the source
> >    really is in a different location than the "normal" URI then your
> >    DAV module probably has no knowledge of it.  Which means now you
> >    have to teach JSP to be DAV-aware and answer PROPFIND requests, or
> >    teach your DAV module all about what URIs are served by which other
> >    modules and how the two URI spaces map to each other.
>
> >
> >My primary objection to GETSRC is that it represents a non-extensible
> >direction to follow.  For example, one of the key purposes
> >of PROPFIND was to provide semantic indexing of web resources, and the
> >indexing of the display information should be significantly different
> >>from the indexing of the source information.  Once you have taught the
> >DAV module to understand the difference between display URL spaces and
> >source URL spaces, it can produce this kind of indexing.  Similarly,
> >any other kind of method that could sensibly be applied to both the
> >display and authoring resources can take advantage of the separation
> >of display and authoring into separate identifiable URLs.
>
> I agree with all of this!  I have no bones whatsoever to pick about
> the superiority of keeping source and display resources separate, or
> its happy consequences.  For an integrated content management system
> you would definitely want this, and it would be pretty darn cool.
>
> What I disagree with is the _requirement_ to keep the two spaces
> separate, which burdens administrators with a lot of extra

There *is no* requirement to keep the spaces separate, just the individual
URIs. For instance, for any given ASP resource "x" you could generate a
DAV:source pointing to "x.~source~", and the serve the source code (and
accept PUTs on the source code) on that URI.

> configuration, isn't understood by most content-generation software
> today (if any), and often confuses the end-users who can barely use
> Dreamweaver/Golive/FrontPage much less understand why their "browser"
> URL is different from their "Dreamweaver" URL.  For most

That's why the DAV:source property was defined. It enables clients to
automatically discover the source URIs (and to offer to edit *them*
instead).

> installations, keeping the URIs the same is a desireable thing and
> does not cause anyone to lose any functionality that they care about.
> Most people don't care about indexing their source, and we have
> specialized crawlers already for indexing display content.

Sorry, but if we can't agree on the simple axiom that different resources
need different URIs, there's really not much point debating.

Again: do you consider the source and the output to be the same resource?

> I'm just saying that the simple things should be easy.  It's a basic
> rule of design.

Yes, but it can be only as simple as reasonable possible.

> I'm not stuck on the GETSRC idea. I'll implement Translate almost as
> happily if that's the direction the group goes.  If the group doesn't

That's just a little syntactic difference. Both share the same problems.

> come up with anything at all, then Translate is likely to become the
> de-facto standard, and you'll end up putting it into RFC-2518-bis2
> anyway.

Translate already *is* a de-facto standard, but that doesn't mean it
automatically qualifies as acceptable solution.

Received on Friday, 1 March 2002 19:47:28 UTC