[Osr-101] Re: Neutron Sitetree response

[Thomas Comiotto]

>
> 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