RE: Hierarchical URLs and Collections

The justification for the syntax requirement that internal members be scoped
by URL hierarchy is that the overwhelming majority of existing hierarchical
storage devices can not implement DAV otherwise. They can not deal with the
concept that deleting http://a/b does not also delete http://a/b/c. Most of
these systems can also not handle having http://a/b/c exist but not
http://a/b.

Furthermore COPY/MOVE become undefined if http://foo/bar is treated as an
"internal" member of http://a/b.

Additionally, the overwhelming majority of hierarchical clients could not
display a storage where http://foo/bar is an "internal" member of http://a/b
and that deleting http://a/b could somehow still keep http://a/b/c around.

Finally, we have already demonstrated that the DM community can implement
their namespace the way they want with the features they want inside the
existing WebDAV framework.

So it seems the WebDAV group has managed to come up with a rule that neatly
allows the vast majority of existing systems to implement DAV without
impeding the higher end systems from using DAV as well. Looks like everyone
won.

		Yaron


> -----Original Message-----
> From: Larry Masinter [mailto:masinter@parc.xerox.com]
> Sent: Sunday, August 23, 1998 12:35 AM
> To: Roy T. Fielding
> Cc: WebDAV working group
> Subject: RE: Hierarchical URLs and Collections 
> 
> 
> |For the most part, WebDAV doesn't define things in terms of the
> |URL syntax.  The only thing it does is internal members, and that's
> |because people did want to require that http://a/b/c be 
> deleted whenever
> |http://a/b/ is deleted.
> 
> If you defined this in terms of 'internal member' rather than 
> syntactically,
> then the requirement would be stated by semantics rather than 
> by the URL
> syntax. This would then not disallow systems that didn't follow the 
> syntactic convention. I think we're talking past each other. Isn't it
> better to not require a syntactic convention if there's no 
> justification
> for it?
> 
> |I am all for a member of a collection that may appear in multiple
> |collections and does not act like an external reference.  
> However, that
> |thing is called a direct reference (or alias) and not 
> 'internal member'.
> 
> You're justifying the design by making reference to the 
> design, so this
> seems like a circular argument. WebDAV has a concept called 'internal
> member', and it maps it onto a syntactic convention. And anything that
> doesn't follow the syntactic convention you have to assign a 
> different concept.
> 
> But the concept works fine without the syntactic convention, in which
> case you wouldn't have to call it something else.
> 
> It sounds like you're trying to _explain_ the design, but I understand
> the design, I'm just asking that the design be changed. If 
> you're explaining
> why you shouldn't change the design, saying "because we 
> called the thing
> you want to do something else" isn't a good justification.
> 
> |Calling both things an 'internal member' makes it impossible 
> to describe
> |the requirements of internal resources that do not exist independent
> |of the collection.
> 
> No! An internal member is something that doesn't exist independent of
> the collection(s) that contain it.  That's the definition, 
> and the requirement.
> Now you have another requirement, which is that "The URL of 
> an internal
> member has a particular syntactic relation to the URL of the 
> container",
> but that requirement isn't justified.
> 
> Larry
>

Received on Sunday, 23 August 1998 15:53:04 UTC