Subject: [[email-masked]: Re: Issue: PROP_ATTR]

From: Greg Stein <[email-masked]>
Date: Fri, 13 Apr 2001 21:16:54 -0700

----- Forwarded message from Laurie Harper <[email-masked]> -----

From: Laurie Harper <[email-masked]>
Subject: Re: Issue: PROP_ATTR
To: Greg Stein <[email-masked]>
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.

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
and the stored value is unlikely to be easily achievable.

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.

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 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
(plain text) value this is just the text value; for structured XML, that
places only reasonable requirements on the DAV server.

L.
-- 
http: www.holoweb.net/~zodiac/   |   jabber: zodiac(@)jabber!org
email: zodiac(@)holoweb!net      |   icq: #78724820
-----------------------------------------------------------------
   condom: general protection error, child process produced.

----- End forwarded message -----

-- 
Greg Stein, http://www.lyra.org/

---

From: "Julian F. Reschke" <[email-masked]>
Date: Sat, 14 Apr 2001 12:23:08 +0200

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

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

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

> 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

> the Infoset of the property's element content.  In the case of a non-XML

...child node content...

> places only reasonable requirements on the DAV server.

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

---

From: Laurie Harper <[email-masked]>
Date: Mon, 16 Apr 2001 13:11:26 -0400

> think there's a strong indication that it actually *is* XML.

No, there's a strong indication that the *representation* is XML but the
semantics of the value are wholy outside of the scope of WebDAV.  That means
it's important not to impose artifacts of the transport encoding on the
meaning of the term property value.

> get it back *exactly* as it is, it should send it as a properly escaped text

Exactly, yes.  That leaves the issue of defining what will and what will not
be preserved in the case where the value is encoded as an XML fragment.  If
it's not going to be a byte-for-byte equivalence, what *is* it going to be?

> wouldn't expect the server to preserve whether it was escaped by CDATA or

I agree, w.r.t. a) and b).  What I'm after is clarification for case c),
preferably based on the Infoset definitions.

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

I'm suggesting that they are part of the XML encoding of the property, not
part of the property value -- an artifact of the encoding that can be
resolved by exclusion.  I also wasn't clear or explicit enough in
identifying my other issue -- defining what a property's value is when
expressed as 'in line' XML.

L.