Subject: Re: Issue: PROP_ATTR

From: [email-masked]
Date: Wed, 11 Apr 2001 10:30:06 +0100

Greg wrote:
> The question isn't about attributes in general, it
> is about *which* attributes. Consider the following:
>
>   <D:prop>
>     <theprop attr1="foo">
>       thevalue
>       <subelem attr2="bar"/>
>     </myprop>
>   </D:prop>
>
> I believe everybody would agree that attr2 gets stored.

Yes.

> The real question is about attr1. I see that attribute
> as part of the element that *names* a property, but it
> isn't part of the property *value*.

That's an interesting comment -- I'd say that everything from the opening
element <theprop... to the closing element </theprop> is the property, and
the outermost element is called its 'name'.  Everything about the property
should be stored, including 'copying down' namespace declarations where
required.

> IMO, PROP_ATTR is about defining the boundary between
> property naming, and a property's value.

I don't think there is a boundary per se, the name is extracted from the
property.

Tim

---

From: "Jim Whitehead" <[email-masked]>
Date: Wed, 11 Apr 2001 10:12:53 -0700

> should be stored, including 'copying down' namespace declarations where

Since persisting the attributes is going to be tricky enough, my leaning is
to only allow namespace and xml:lang attributes in the property name tag.

However, I do agree that servers MUST persistently store XML attribute
information found in the value of the property. I don't care how they store
it -- the XML is just a marshalling format. I agree with the suggestion to
look at the XML Canonicalization Recommendation for ideas on how to specify
the round-trip behavior <http://www.w3.org/TR/xml-c14n>.

It's important to support XLink style linking
<http://www.w3.org/TR/2000/PR-xlink-20001220/>, and this is *very* dependent
on the use of attributes.  Storage of XLinks in DAV properties is a very
natural way to persistently attach link metadata to a resource -- the major
roadblock holding this up at present is the fact that, right now, a client
does not have a guarantee that attribute information will be persistently
stored.  I'm glad to see the sentiment of the working group leaning in this
direction.

- Jim

---

From: "Julian F. Reschke" <[email-masked]>
Date: Wed, 11 Apr 2001 19:36:55 +0200

Let's try to approach it this way:

A property is a tupel of (namespacename, localname, content).

content can be (for instance) empty, a string, or mixed XML content. By
definition, it can by anything that belongs to the property element's
infoset (including anything below it).

If "content" is not a simple string, it needs to be stored in an
XML-friendly way. For instance, elements or attributes in the content might
use namespace prefixes that have been defined outside that element. For
instance:

<proppatch xmlns="DAV:" xmlns:x="foo"><set>
<prop>
<bar><x:baz/></bar>
</prop>
</set></proppatch>

If attributes of the property itself need to be recorded as well, that's
extremely easy to do: just instead of storing the "content" of the element,
you store the XML serialization of the element including it's attributes and
children.

Two other notes:

a) It needs to be specified which parts of the Infoset are preserved
(comments, processing instructions)? I'd say: all of them.

b) Microsoft's webfolders already use the old XML data namespace to put data
type information into properties, for instance <DAV:getlastmodified
dt:type="isoDate.tz" />.

Julian

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jim Whitehead
> Sent: Wednesday, April 11, 2001 7:13 PM
> To: WebDAV WG
> Subject: RE: Issue: PROP_ATTR
>
>

---

From: "Julian F. Reschke" <[email-masked]>
Date: Thu, 12 Apr 2001 00:38:11 +0200

Hi,

a few questions/comments:

1) 2.2.4	DAV:supported-live-property-set (protected)

<!ATTLIST supported-live-property namespace NMTOKEN "DAV:">
namespace value: an XML namespace

This seems to indicate that only properties in the DAV: namespace can be
live properties, which I think is wrong.

2) General comment regarding new required properties for all resources

Unless I'm making a mistake, this makes propfind/allprop extremly chatty...

Regarding "supported-method-set" -- what is it for? If I really would need
to know this, couldn't I just do OPTIONS on the resource?

Regarding "supported-live-property-set": this *is* very useful, but it seems
it could be implemented simpler and more effective by extending
propfind/propname to include this information, for instance:

>>Request

   PROPFIND  /container/ HTTP/1.1
   Host: www.foo.bar
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <propfind xmlns="DAV:">
     <propname includeTypeInfo="yes"/>
   </propfind>

>>Response

   HTTP/1.1 207 Multi-Status
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <multistatus xmlns="DAV:">
     <response>
          <href>http://www.foo.bar/container/</href>
          <propstat>
               <prop xmlns:R="http://www.foo.bar/boxschema/"
xmlns:dav="DAV">
                    <R:bigbox dav:type="dead" />
                    <R:author dav:type="dead" />
                    <creationdate dav:type="protected" />
                    <displayname dav:type="live" />
                    <resourcetype dav:type="protected" />
                    <supportedlock dav:type="protected" />
               </prop>
               <status>HTTP/1.1 200 OK</status>
          </propstat>
     </response>
   </multistatus>

Obviously this could also be made propfind/propinfo (new propfind type), and
it could also use child elements rather than attributes
(<creationdate><protected /></creationdate>...).

3. 2.1.1	Creating a Version-Controlled Resource and
   2.3.1	DAV:checked-in (protected)

OK, under core versioning, every version is a resource on it's own. Does
this mean that a server has to assign a unique URL and make the version
resource visible under this URL, for instance for PROPINFO? Or is this
optional?

Regards,

Julian