views:

24

answers:

1

See this example from RFC2518:

    <D:multistatus xmlns:D="DAV:">
      <D:response>
           <D:href>http://www.foo.bar/container/&lt;/D:href&gt;
           <D:propstat>
                <D:prop xmlns:R="http://www.foo.bar/boxschema/"&gt;
                     <R:bigbox>
                          <R:BoxType>Box type A</R:BoxType>
                     </R:bigbox>
                     <R:author>
                          <R:Name>Hadrian</R:Name>
                     </R:author>
                     <D:creationdate>
                          1997-12-01T17:42:21-08:00
                     </D:creationdate>

WebDAV allows the getting/setting of in part predefined or arbitrary key/value pairs. Here one prop retrieved is from the "DAV:" namespace, "creationdate", abbreviated as "D". Another is from the "http://www.foo.bar/boxschema/" namespace, indicated by its shorthand "R".

I undersstand the first one, but what about the second? As a JSON data structure this reads as

{
  "DAV:": {
     "creationdate": "1997-12-01T17:42:21-08:00"
  },
  "http://www.foo.bar/boxschema/": {
     "bigbox": {
        "BoyType" : "Box Type A"
     },
     "author": {
        "Name" : "Hadrian"
     }
  }
}

As I understand WebDAV, resources should be able to set/get key-value-pairs, but the RFC here presents a nested multi-level data structure! How should I flat these out to key-value pairs? Or do I get the nesting in the XML wrong, is there something that I need to throw away/skip? That would explain it...

$key{'DAV:creationdate'} = "1997-12-01T17:42:21-08:00";
$key{'http://www.foo.bar/boxschema/.bigbox.BoxType'} = "Box Type A";

or what?? How do you guys handle these? Any help appreciated!

+1  A: 

You really should be looking at RFC 4918, not RFC 2518.

To answer your question: WebDAV properties essentially are XML fragments, which can be simple (plain text), or more complex. See Section 4.3 for details.

And yes, this is hard to represent in JSON.

Julian Reschke
Thanks for the quick hint!From a glance at RFC4918 and your answer, I begin to realize (accepting it will take another few hours) that the WebDAV properties are in no way an extension of what has become known as filesystem xattr(ibs), so I won't be able to fully/(easily) implement WebDAV's property demands via my filesystem's extended attributes API.Tell me if I am wrong (please do!) aargh...
You can always force this type of property content into strings, after all, that's what you have in PROPFIND and PROPPATCH. Of course it's non-trivial if you want these properties to be exposed to non-WebDAV clients. I think the easiest approach is to simply reject mixed content, although this will make the implementation non-conforming. Depends a bit on your requirements.
Julian Reschke
Diverging a bit from the RFC is also what I had in mind - at least for now. Still, I think WebDAV went a little far there, with requiring PROPPATCH to support simple key-value pairs *and* more complex structures.. If they had saved the more complex part for a Class n spec and kept simpler key-value for Class 1 servers, I think more people would use this feature. -- Probably that's why so many implementations lack PROPPATCH support...
Just for the record: any hint on how to more or less reliably parse out those varied simple and mixed content requests into a predictable structure? - At the moment I can't see how I may teach my script to look for all the possible locations of namespaces, how to tell the parser about depth limits, etc. (I am working under Perl)
You're using an XML parser, right? It should provide you with all the information you need...
Julian Reschke