also since one can use PROPFIND as an alternative method I think
this makes sense, because otherwise
we basically would have to limit it to GET only because and I guess
it would be strange to receive some custom neutron XML back from
a PROPFIND request.
No - the same rules would apply like for any other Neutron command
(open, save, lock, unlock etc.); server implementors are free to
choose how and where to make the corresponding data available.
Whatever transport protocol, commandURIs and protocol methods suit
their needs. A server implementor might even decide to use PROPFIND
for serving out Neutron sitetree data.
Also I think there are some systems out there which already have
PROPFIND implemented
Yes sure - but I would not rely on that and I think it's a big
strength of Neutron that can be added on top of almost any server
configuration out there - without changing that configuration!
Neutron IO even tackles the most widespread szenario: authoring a
small website hosted on a static server with ftp write access only.
Also, is the Neutron variant of a webDAV multipart response bound
to the URI namespace rules the webDAV spec does enforce?
you mean xmlns="DAV:" ?
WebDAV operations rely on certain conventions with regards to how the
content server organizes its URI namespace (the way the URIs i.e.
document are organized). For instance, you can't model collections in
a arbitrary way. The spec says:
"A collection is a resource whose state consists of at least a list
of internal member URIs and a set of properties, but which may have
additional state such as entity bodies returned by GET. An internal
member URI MUST be immediately relative to a base URI of the
collection. That is, the internal member URI is equal to a containing
collection's URI plus an additional segment for non-collection
resources, or additional segment plus trailing slash "/" for
collection resources, where segment is defined in section 3.3 of
[RFC2396]."
Put aside systems that use highly parametrized URIs, here's an example:
/ Root Collection
/fruits.html Member of Root
/fruits_en.html Member of Root
/fruits_de.html Member of Root
/fruits/ Fruits collection
/fruits/fruits.png Member of Fruits
/fruits/apple.html Member of Fruits
/fruits/apple_en.html Member of Fruits
/fruits/apple_de.html Member of Fruits
/fruits/apple/apple.png Member of Apple
Adding DAV:collection properties to URIs does imply that you can for
example MOVE /fruits to /juicyFruits which is fine with the apples -
but in case of Lenya not so fine with /fruits.html Therefore Lenya
collections should read something like this:
/fruits/fruit.html
/fruits/fruit_en.html
/fruits/fruis.png
/fruits/apple/apple.html
[..]
This can be done by doing some sort of proxying. Introduce a WebDAV
area or better multiple areas for different views. That's a bit of an
overhead for simply serving out sitetree data, isn't it?
But it get's even worse, because what you might want to is:
/fruits.html Collection
/fruits/apple.html Member of fruits.html
Which is not WebDAV compliant.
My point is that if you serve out a site description format that has
DAV:collection properties in it, you suggest that the corresponding
resource can be dealt with as a WebDAV resource. But in the case of
Neutron you might not even deal with a server that supports PROPFIND.
Also, if sitetree data is simply needed for providing a introspection
parser with hints about what resources are available on a server, why
not use a Google Sitemap for that?
Another question is if webDAV lingo is sufficient for what
neutron clients might want to provide users with. Suppose a
client wants to provide users with a tree view on a Lenya
publication like the Lenya site tab does: i.e. tabs for
switching between different language versions of a site where
missing items are replaced by grayed out placeholders pointing
to a default language version. Can you give an example of how
this could be done in a nice way by using webDAV vocabulary only
- or possibly enriched webDAV?
I guess this could be by enhancing the WebDAV with some neutron
elements with the neutron namespace
Yes sure.
Here's what we use at UZH in our 1.2 publication to spit out
sitetree data. It's rdf that uses the following custom tags:
- map:navigation A navigational structure
- map:node A navigation node
- map:childNodes Child nodes
- map:resources Resources bound to a node (e.g. documents in
various langauges document)
thanks for sharing this. As said I will open an amendment and then
we can start adding pros and cons.
Cool, thanks!
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
