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 03:46:18 UTC