Subject: RE: RFC2518 bis, attributes on property names -- in or out?

From: Jason Crawford <[email-masked]>
Date: Thu, 28 Nov 2002 14:20:31 -0500

My preference is to keep things the way it is in 2518bis.  I don't feel so 
strongly about keeping all the attributes on the propertyname tag, but I 
definitely don't wan't to agonize over it if there is no strong case to be 
made either way.

I do want to hear more about what Joel Soderberg encountered that would make it lean away from persisting random 
attributes.

I do agree with Julian that the namespace persistance issue is pretty 
clear, but I'll resurrect the discussion on property value roundtripping 
and see if we can nail that issue and all sub issues shut.

J.

------------------------------------------
Phone: 914-784-7569

---

From: "Joel Soderberg" <[email-masked]>
Date: Thu, 28 Nov 2002 11:54:50 -0800

Preserving namespaces is almost a given (I would be surprised if that was not already being done by most implementations).  However, I don't believe that the namespace aliasing must be preserved.  When returning the value, different aliases may be used.  

This has no bearing, though, on random attributes (metadata) on the property name.  If you force persistance of these items, that means that you dictate a storage format that is XML.  WebDAV should not be in the business of dictating formats.  

If the only reason for asking for persistance is for namespacing, there are other ways that information can be retained that does not tie the hands of the non-XML based property storage.

Joel

-----Original Message-----
From:	Jason Crawford [mailto:[email-masked]]
Sent:	Thu 11/28/2002 11:20 AM
To:	Julian Reschke
Cc:	Lisa Dusseault; Webdav WG
Subject:	RE: RFC2518 bis, attributes on property names -- in or out?

J.

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 28 Nov 2002 21:38:34 +0100

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Joel Soderberg
> Sent: Thursday, November 28, 2002 8:55 PM
> To: Jason Crawford; Julian Reschke
> Preserving namespaces is almost a given (I would be surprised if that was
> not already being done by most implementations).  However, I don't believe

If you're referring to namespaces of property names -- sure. A property is
identified by an XML name, and if an implementation looses half of it (the
namespace), it's simply broken.

> that the namespace aliasing must be preserved.  When returning the value,
> different aliases may be used.

Yes, for the property name itself. But not for any child elements contained
inside the property. And probably undecided for attributes on the property
element itself.

> This has no bearing, though, on random attributes (metadata) on the
property
> name.  If you force persistance of these items, that means that  you
dictate
> a storage format that is XML.  WebDAV should not be in the business of
> dictating formats.

I don't understand these statements. The format for WebDAV property values
*is* XML. So if you can't persist a dead property with nested child elements
(and attributes on those for that matter), you're not compliant to RFC2518.
The *only* controversial thing here is whether attributes that appear *on*
the property name element itself are part of the value to be persisted.

So you need to be able to persist XML anyway -- how does persisting
attributes on the property itself make things harder?

> If the only reason for asking for persistance is for namespacing,  there
are
> other ways that information can be retained that does not tie the hands of
> the non-XML based property storage.

In general, to be compliant with RFC2518 you can't use an XML-unfriendly
property storage. Whether attributes are in and out seems to be of little
importance here.

I'm happy to discuss this as a new issue (for instance, are servers allowed
to only persist the immediate child text nodes of a property element as a
string?), but this is definitively a new requirement.

Note that both IIS and moddav (the most widely deployed WebDAV servers) *do*
persist XML in property values, so we have proven interoperability in this
point.

Finally (as mentioned many times before), the best way to *precisely* define
these things is to use the terminology from the XML Infoset spec, and the
guidelines from section 2.4 (document subsets) of RFC3076.

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: "Joel Soderberg" <[email-masked]>
Date: Fri, 29 Nov 2002 08:51:37 -0800

Couple more comments inline....

-----Original Message-----
From:	Julian Reschke [mailto:[email-masked]]
Sent:	Thu 11/28/2002 12:38 PM
To:	Joel Soderberg
Cc:	Webdav WG
Subject:	RE: RFC2518 bis, attributes on property names -- in or out?

[js] Yes, but even more so, I am talking about any namespaces used in the 
context of the proptery value.  An implementation must be smart about this
such that any namespace defined above the property value scope is persisted
if it is used in the property value.  There is nothing in the DAV drafts that
requires all namespaces used in a property value to be defined or redefined
at the property/value level.

[js] Why?  This is an arbitrary requirement, no?  Namespaces are not tied
to an alias outside of any document.  I believe (although I may be wrong), that
the namespace documents even indicate tha the revelence of the alias outside
of the current document cannot be relied on.  It should be perfectly allowable
for an implementation to persist the namespace/tag pairs instead of having to
persist the alias.  I can think of at least three different DAV server 
implementations that model behavior that way.

property
dictate

[js] Actually, I'll take this bit offline with you -- I get back to the office on
Monday.

[js] Needing to persist XML does not mean that everything is XML, true?
I can point you to a couple of DAV implementations that use the XML datatype
draft (that I think is long since forgotten) that honors a DT attribute and will
persist the value in that format.  There is nothing in the drafts that prevent
this behavior, and nothing should be added that would suddenly make such 
implementations non-compliant.

are

[js] Again, XML friendly is not the same as XML exclusive.  I don't think
forcing the hands of server developers to XML is a goal of the DAV drafts
and should not added to the BIS.

[js] I don't believe it is a new requirement.  I believe it is a reasonable
option that allowed DAV server developers to add-value to their 
implementations.  It certainly was not required, but it also was not forbidden.

[js] Again, I will take this offline, but no.  You have interop with implementations
that persist the XML values, they don't always persist random attributes in the value
node.

Julian

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 29 Nov 2002 18:20:57 +0100

> Sent: Friday, November 29, 2002 5:52 PM
> To: Julian Reschke
> Cc: Webdav WG

Correct.

> implementations that model behavior that way.

Well, I would have agreed with this a few years ago. Since then, W3C
recommendations have been published in which the alias itself has become
significant as well (for instance, when using QNames in attribute values).
So yes, to round-trip XML contents you need the aliases as well.

> ...

True.

> implementations non-compliant.

I didn't intend to do that. Actually, our server does honor the XML Schema
xsi:type attribute to do the same thing (see [1]).

are

It's not.

> > the non-XML based property storage.

Does it? The server needs to decide on a case-by-case basis anyway. If the
property value contains for instance nested elements, in general you can't
persist it non-XML. Having an "unexpected" attribute is just another case.

> and should not added to the BIS.

Again, nobody said that. If a server thinks that it can round-trip a
property value internally using a non-XML format, it's free to do so.

> implementations.  It certainly was not required, but it also was not

It's *allowed* to choose an optimized internal representation. It's however
*required* to be able to persist arbitrary XML.

> that persist the XML values, they don't always persist random attributes
in
> the value node.

I'll check, but anyway...: if they're able to do the one thing (nested
element content), where's the problem doing the other thing as well?

> ...

[1]
<http://greenbytes.de/tech/Webdav/draft-reschke-webdav-property-datatypes-la
test.html>