Subject: RE: Issue: PROP_ATTR

From: "Clemm, Geoff" <[email-masked]>
Date: Fri, 13 Apr 2001 14:34:36 -0400

For dead properties, I don't see the issue wrt storing attribute values
for the root element.  If you are storing attributes on all the nested
elements (as I believe everyone has agreed), it should be trivial 
to store it on the root element as well.

For live properties, where the server can take advantage of its knowledge
of the value space for the live property values, then I agree that it
could be an issue.

So I still prefer saying MUST on all attributes of dead properties,
and "as specified in the property definition" for live properties. 

Cheers,
Geoff

-----Original Message-----
From: Kevin Wiggen [mailto:[email-masked]]
Sent: Friday, April 13, 2001 12:02 PM
To: Greg Stein; WebDAV WG
Subject: RE: Issue: PROP_ATTR

I agree with Greg et all that "attr2" needs to be stored.

I believe that allowing "attr1" could lead to some interop problems, or we
need to spec this out a little better:

<D:prop>
  <theprop attr1="foo"/>
  <theprop attr1="bar"/>
  <theprop attr2="fee"/>
</D:prop>

Is that legal?  Does the attribute make the property unique?  Does simply
the value of an attribute make it unique?  Or do we (like xmllang) simply
store one set of attributes for a property?

Also how does one use Dasl with attributes on properties?

I would like to see attributes on the property name not be supported.

Kevin

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Greg Stein
Sent: Wednesday, April 11, 2001 1:06 AM
To: WebDAV WG
Subject: Re: Issue: PROP_ATTR

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

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

Cheers,
-g

On Tue, Apr 10, 2001 at 10:58:21PM -0700, Eric Sedlar wrote:
> I agree.  There is no reason not to persist attributes.
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Mark A. Hale
> > Sent: Tuesday, April 10, 2001 6:29 PM
> > To: WebDAV WG
> > Subject: RE: Issue: PROP_ATTR
> >
> >
> > Jim:  Thanks for getting the issues list started.
> >
> > I believe that WebDAV must permit properties to have attributes.
> > As you've
> > pointed out, RDF and PRISM do use them extensively.  A server can
reformat
> > the attributes in a subsequent PROPFIND request.  Attrbiutes should be
> > persistent.
> >
> > 	Thanks,
> >
> > 	Mark
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]]On Behalf Of Jim Whitehead
> > > Sent: Tuesday, April 10, 2001 5:54 PM
> > > To: WebDAV WG
> > > Subject: Issue: PROP_ATTR
> > >
> > >
> > > As mentioned in a previous post, now is the time to start
> > resolving issues
> > > on the RFC 2518 issues list.  As fate would have it, the first
> > > issue on the
> > > list is one that has been contentious in the past. Can we come to
> > > consensus
> > > on it now?
> > >
> > > Issue: PROP_ATTR
> > >
> > > Description:
> > >
> > > What is a WebDAV server required to do with XML attributes other than
> > > xml:lang submitted with a PROPPATCH?  This affects how well
> > WebDAV will be
> > > able to support RDF, since RDF uses attributes extensively.
> > >
> > > Greg Stein originally raised this issue:
> > >
> > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0089.html
> > >
> > > See also:
> > >
> > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0092.html
> > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0094.html
> > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0095.html
> > >
> > >
> > >
> > >
> > >
> >
> >

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

---

From: Greg Stein <[email-masked]>
Date: Fri, 13 Apr 2001 13:46:24 -0700

The issue is that <theprop> provides the name. The stuff inside that is the
property value. Attributes on the root are associated with the name, not the
value.

Haven't we always tried to use element nesting as a means of structure?
Don't we tend to say that attributes are modifiers for the element they
occur on?

I'd rather not see attributes on the name supported. On the value, sure.

Maybe people are thinking that the name element is stored with the value. I
see it more as the name is a key, which then maps to the value. Further, the
name (key) is broken into a tuple of (localpart, namespace-uri, xml:lang),
so I don't see it as stored as XML with the rest of the value. And since it
isn't in XML format, it becomes very difficult to store things such as
attributes.

Let's say that you *do* choose to store the name with the XML value. How do
you manage the namespace and xml:lang. Does the property always have to
store a private namespace to ensure that you don't get prefix clashes? For
example:

  <P:myprop xmlns:P="private-namespace-prefix-marker">value</P:myprop>

(as opposed to collecting a union of all namespace prefixes and placing them
 on a higher element)

In the store-with-value approach, you're duplicating the data from the key
to the value. Maybe the word "normalization" is too loud in my head :-), but
I prefer not to do that.

Cheers,
-g

---

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

> Sent: Friday, April 13, 2001 10:46 PM
> To: WebDAV WG

We need to define what the value of a property is:

a) the Infoset of the child elements of the element node (minus: comments?
processing instructions?)
b) the Infoset of the property element itself.

I'd still prefer b).

> Don't we tend to say that attributes are modifiers for the element they

Yes, but they still belong to it's XML Infoset.

> Maybe people are thinking that the name element is stored with

That's certainly a simple way to preserve the attribute information.

> name (key) is broken into a tuple of (localpart, namespace-uri, xml:lang),

Why do you say that xml:lang is part of the key? That would indicate that

<set xmlns="DAV:">
  <displayname xml:lang="en">Contents</displayname>
  <displayname xml:lang="de">Inhalt</displayname>
</set>

would set two different properties, which I don't believe is true.

> isn't in XML format, it becomes very difficult to store things such as

Make the key (namespace-uri, local-name) and the value "XML serialization of
the property element", and you're done.

> (as opposed to collecting a union of all namespace prefixes and

I'd say that's absolutely up to the implementation. You just have to make
sure that upon PROPFIND, all element's appear in their original namespace.

> to the value. Maybe the word "normalization" is too loud in my

Actually, it would avoid having xml:lang as part of the key, which IMHO is
wrong.

---

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

Sounds good.

> [mailto:[email-masked]]On Behalf Of Clemm, Geoff
> Sent: Friday, April 13, 2001 8:35 PM
> To: WebDAV WG

---

From: Greg Stein <[email-masked]>
Date: Sat, 14 Apr 2001 16:58:17 -0700

On Sat, Apr 14, 2001 at 12:23:56PM +0200, Julian F. Reschke wrote:
>...

Sorry... I didn't mean to imply that. I meant that the name element has
three useful pieces of information, which must be recorded. As you suggest,
only the localpart and URI are the "key". The xml:lang is effectively part
of the value.

[ this is how it is implemented in mod_dav today ]

>...

I maintain that it should be the serialization of the contents of the name
element, but exclude the name element itself. For example:

  <prop>
    <myprop>
      contents
      <child-elem att="foo"/>
    </myprop>
  </prop>

In the above example, I see the value as 'contents<child-elem att="foo"/>'
(mod_dav actually preserves whitespace; I just omitted it here for clarity).

Further, there may be an xml:lang that applies to the "scope" that the
property value occurs within. The name is separate, and is a tuple of
(localpart, namespace-URI).

I believe this is the appropriate interpretation; the <myprop> element (and
any attributes on it) are the name, not the value.

> sure that upon PROPFIND, all element's appear in their original namespace.

I completely agree.

My point is that it is more difficult for server implementors if you want to
state that the attributes on the name element are part of the property
value, and (thus) need to be stored.

Cheers,
-g

---

From: "Julian F. Reschke" <[email-masked]>
Date: Sun, 15 Apr 2001 11:14:33 +0200

> Sent: Sunday, April 15, 2001 1:58 AM
> To: WebDAV WG

<sigh/>

> any attributes on it) are the name, not the value.

As I said, both point of views are possible. However, your position seems to
be:

value = Infoset of all child elements *plus* the optional xml:lang attribute

How do you put the value of xml:lang into the serialization of the element's
contents? Sure, that's again an implementation issue, but including the
element itself certainly makes it easier.

> value, and (thus) need to be stored.

While my point is that it makes absolutely no difference at all :-)

Maybe we need to collect all issues regarding this topic before going back
to this one. For instance, if somebody would want to store an XSLT or an XSD
schema as a property value, he probably would expect that namespace prefix
information is preserved as well...

Julian

---

From: Greg Stein <[email-masked]>
Date: Sun, 15 Apr 2001 13:54:00 -0700

> value = Infoset of all child elements *plus* the optional xml:lang attribute

Yes, because the xml:lang value is scoped, and the property value occurs
within that scope.

And this isn't just because xml:lang occurs on the property name element; it
could be three levels higher in scope.

> element itself certainly makes it easier.

Nope. It could occur higher in scope, so it might not be on the property
name element at all. Thus, serializing the name isn't going to help with
preserving the xml:lang value.

I store the xml:lang and the (serialized) value as two items of data in the
property database.

> While my point is that it makes absolutely no difference at all :-)

As an implementor of a server, I would disagree :-)

I just want to see the language state something to the effect of: all
attributes on elements, which are children of the name element, MUST be
preserved; attributes on the name element MAY be preserved. [ plus the
language about xml:lang ]

> information is preserved as well...

They're SOL with (at least) mod_dav. It doesn't preserve prefixes. That is
potentially another issue for the RFC 2518 issues list (I have an opinion,
but that can occur under a separate issue thread).

Cheers,
-g

---

From: "Julian F. Reschke" <[email-masked]>
Date: Mon, 16 Apr 2001 01:09:43 +0200

> Sent: Sunday, April 15, 2001 10:54 PM
> To: WebDAV WG

Well, it can if you just replicate the xml:lang value "into" the property
element.

---

From: "Julian F. Reschke" <[email-masked]>
Date: Mon, 16 Apr 2001 14:25:07 +0200

> could be three levels higher in scope.

I've got a concern here... RFC2518 makes a special case for xml:lang, which
I think is a bad thing. "Canonical XML" [1][2] specifies rules for
generating canonical representations of document subsets (which seems to be
relevant to our problem), and it states that *all* attributes in the xml
namespace are inherited (as of today, this would include xml:space as well).

Also note that other working groups might be adding more attributes to the
xml namespace, such as xml:base [3]. I think it should be considered to
either drop the requirement to persist xml:lang with the property value, or
to extend the requirement so that all attributes from the xml namespace [4]
are treated equally.

Julian

[1] <http://www.w3.org/TR/xml-c14n#DocSubsets>,
[2] <ftp://ftp.rfc-editor.org/in-notes/rfc3076.txt>,
[3] <http://www.w3.org/TR/2000/PR-xmlbase-20001220/>,
[4] <http://www.w3.org/XML/1998/namespace>

---

From: "Julian F. Reschke" <[email-masked]>
Date: Mon, 16 Apr 2001 16:39:58 +0200

> [mailto:[email-masked]]On Behalf Of Kevin Wiggen
> Sent: Monday, April 16, 2001 4:30 PM
> DAV servers cannot preserve the namespace prefix.  What would

What do you mean by "cannot"? Preserving something doesn't necessarily mean
that it needs to contribute to the property's uniquess criteria (like
xml:lang).

> happen if two
> proppatch's told the same resource to store properties with the same
> prefixes but differing namespaces?  When the server went to
> output info on a
> propfind, it would not be consistent.

I think this is a misunderstatement. We were talking about prefix
preservation *inside* property values, like:

<prop xlmns="DAV:">
	<stylesheet xmlns="foo">
		<xsl:transform version="1.0" xmlns:xsl="http...">
			...
		</xsl:/transform>
	</stylesheet>
</prop>

However, whether the prefix of the property *itself* needs to be preserved
(although it does not contribute to the key) is yet another open question...

Julian

---

From: "Kevin Wiggen" <[email-masked]>
Date: Mon, 16 Apr 2001 07:30:17 -0700

>but that can occur under a separate issue thread).

DAV servers cannot preserve the namespace prefix.  What would happen if two
proppatch's told the same resource to store properties with the same
prefixes but differing namespaces?  When the server went to output info on a
propfind, it would not be consistent.

<d:prop xmlns:f="http://www.xythos.com/namespaces">
  <f:bar/>
</d:prop>

and

<d:prop xmlns:f="fdfd">
  <f:bar/>
</d:prop>

Kevin

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Greg Stein
Sent: Sunday, April 15, 2001 1:54 PM
To: WebDAV WG
Subject: Re: Issue: PROP_ATTR

Cheers,
-g

---

From: "Julian Reschke" <[email-masked]>
Date: Sun, 22 Apr 2001 22:12:25 +0200

Hi,

I've spent some time looking at the current RFC, and what needs to be done
to get this subject defined more precisely.

The wording on property names seems to be OK (if the appendix about the non
W3C-complaint name matching is removed). It probably could be less vague on
what it means by a "schema", though. In addition, I would propose to have
the section about property names moved *in front* of the section about
property values (so 4.4 and 4.5 would be exchanged).

I've also tried to add text to 4.4 that specifies the current consensus on
how XML attributes in the property element are treated... Here's my attempt
(comments are welcome):

4.4.  Property Values
The value of a property when expressed in XML MUST be well formed.

XML has been chosen because it is a flexible, self-describing, structured
data format that supports rich schema definitions, and because of its
support for multiple character sets. XML's self- describing nature allows
any property's value to be extended by adding new elements. Older clients
will not break when they encounter extensions because they will still have
the data specified in the original schema and will ignore elements they do
not understand. XML's support for multiple character sets allows any
human-readable property to be encoded and read in a character set familiar
to the user. XML's support for multiple human languages, using the
"xml:lang" attribute, handles cases where the same character set is employed
by multiple human languages.

TEXT BELOW WAS ADDED...

The value of a property is defined in terms of the W3C recommendation "XML
Information Set" [XML-INFOSET] and "Canonical XML" [RFC3076]. It consists of
a subset of the property element's information items, of which some are
optional (that is, a server MAY choose not to persist them).

    [prefix]
    (optional) The namespace prefix part of the element-type name.
    [children]
    (required) An ordered list of child information items, in document
order. Note that the full Information Set of each child is part of the
value.
    [attributes]
    (optional) An unordered set of attribute information items.
    [namespace attributes]
    (optional) An unordered set of attribute information items, one for each
of the namespace declarations.
    [in-scope namespaces]
    (optional) An unordered set of namespace information items, one for each
of the namespaces in effect for this element.
    [base URI]
    (optional) The base URI of the element, as computed by the method of XML
Base.

In addition, attributes from the XML namespace
(http://www.w3.org/XML/1998/namespace) are inherited by means of section 2.4
of [RFC3076]:

    xml:lang
    (required)
    other attributes from the XML namespace
    (optional)

4.4.1.  Examples for property values
Set request:

  <propertyupdate
	  xmlns="DAV:" xmlns:foo="http://foo.bar.com"
xmlns:x="http://www.w3.org/XML/1998/namespace"
		xml:lang="en" x:space="preserve">
	  <set>
	    <foo:bar attr="test">xyz</foo:bar>
	  </set>
  </propertyupdate>

Inheritance of attributes from XML namespaces as defined in section 2.4 of
[RFC3076]:

  <propertyupdate
	  xmlns="DAV:" xmlns:foo="http://foo.bar.com"
xmlns:="http://www.w3.org/XML/1998/namespace"
		xml:lang="en" x:space="preserve">
	  <set>
	    <foo:bar attr="test" xml:lang="en" x:space="preserve">xyz</foo:bar>
	  </set>
  </propertyupdate>

The value of the property named ("http://foo.bar.com", "bar") thus is:

    [prefix]
    "foo"
    [children]
    3 character information items
    [attributes]
    attribute information items, describing "attr", "xml:lang" and "x:space"
    [namespace attributes]
    (empty)
    [in-scope namespaces]
    the namespace information items (no value, "DAV:"), ("foo",
"http://foo.bar.com"), ("x", "http://www.w3.org/XML/1998/namespace"),
("xml", "http://www.w3.org/XML/1998/namespace")
    [base URI]
    no value

Removal of optional information:

  <propertyupdate
	  xmlns="DAV:" xmlns:foo="http://foo.bar.com"
xmlns:x="http://www.w3.org/XML/1998/namespace"
		xml:lang="en" x:space="preserve">
	  <set>
	    <foo:bar xml:lang="en">xyz</foo:bar>
	  </set>
  </propertyupdate>

The value of the property named ("http://foo.bar.com", "bar") then becomes:

    [children]
    3 character information items
    [attributes]
    attribute information item, describing "xml:lang"