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: Friday, November 29, 2002 5:52 PM
> To: Julian Reschke
> Cc: Webdav WG
> Subject: 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.

Correct.

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

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.

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

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.

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

> > If the only reason for asking for persistance is for namespacing,  there
are

It's not.

> > other ways that information can be retained that does not tie the hands
of
> > 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.

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

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.

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

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

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

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>

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

Received on Friday, 29 November 2002 12:21:32 UTC