RE: [zodiac@holoweb.net: Re: Issue: PROP_ATTR]

> From: Laurie Harper <zodiac@holoweb.net>
> Subject: Re: Issue: PROP_ATTR
> To: Greg Stein <gstein@lyra.org>
> Date: Thu, 12 Apr 2001 11:38:41 -0400
>
> Greg Stein wrote:
> > IMO, PROP_ATTR is about defining the boundary between property
> naming, and a
> > property's value.
>
> I'd say this is exactly scope of the issue.  There is no reason why a
> property's value should be considered to be XML just because it is
> transported in an XML encoding.

But by using XML as transport layer *and* by having examples of DAV:
properties that *do* have XML content (for instance <DAV:resourcetype />, I
think there's a strong indication that it actually *is* XML.

> The problem is that, if the characters between the property's
> start and end
> tag *look like* XML then they are likely going to get processed by the DAV
> server *as* XML, meaning that byte-for-byte equivalence between the input

They need to.

> and the stored value is unlikely to be easily achievable.

Which shouldn't be an issue. If a client wants to set a dead property and
get it back *exactly* as it is, it should send it as a properly escaped text
node.

> Since an XML fragment can always be escaped (via a CDATA section or what
> have you) so that it does not get processes as XML by the DAV server's
> parser, all that is necessary is to define what the server is
> required to do
> with property values that are specified as inline XML.  In that case,
> requiring the server to preserve all info items defined by the XML Infoset
> is probably the strictest reasonable constraint.

That doesn't need to be defined at all. All the server will see is a
property with one (or more) text nodes. For instance

a) <resourcetype><![CDATA[<collection />]]></resourcetype>

isn't different from

b) <resourcetype>&lt;collection /&gt;</resourcetype>

but is completely different from

c) <resourcetype><collection /></resourcetype>

For a) and b), PROPFIND will return an escaped string as value, and I
wouldn't expect the server to preserve whether it was escaped by CDATA or
not.

> So, what does that imply about preserving attributes on the property's
> enclosing element?  As I see it, xml:lang and namespace declaration
> attributes are directly significant, as are any other namespaces
> in scope.
> All other attributes are part of the Infoset of the property's
> XML encoding
> but are *not* part of the property value itself (how would such

Whether those attributes are part of the property's value is exactly the
question that needs to be decided. I think both views are valid, we need to
choose one.

> an attribute
> contribute to a Base64 encoded jpeg image property value, for example?).



> That can all be summed up consistently by saying that a
> property's value is
> the Infoset of the property's element content.  In the case of a non-XML

...child node content...

> (plain text) value this is just the text value; for structured XML, that
> places only reasonable requirements on the DAV server.

I agree, but the same remains true if we include the attribute nodes...

Received on Saturday, 14 April 2001 06:23:38 UTC