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

Couple more comments inline....

-----Original Message-----
From:	Julian Reschke [mailto:julian.reschke@gmx.de]
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?

> From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
> Behalf Of Joel Soderberg
> Sent: Thursday, November 28, 2002 8:55 PM
> To: Jason Crawford; Julian Reschke
> Cc: Lisa Dusseault; Webdav WG
> Subject: RE: RFC2518 bis, attributes on property names -- in or out?
>
>
> 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.

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

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

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

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

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

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

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

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

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

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.

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

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.

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

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