Subject: RE: New RFC2518bis draft

From: "Lisa Dusseault" <[email-masked]>
Date: Wed, 3 Jul 2002 17:26:42 -0400

Julian, I've made a number of your suggestions exactly, or used them to
guide me to do a better job. I have comments on some others.

> Section 2.2: where to put xml:lang attribute
> 
> This may need to be clarified, but a better place is to do it where
> property
> values are defined.

I think this is part of a larger discussion... I don't recall any
opinions from others yet.

> Section 3.3: Attributes in property values are significant.
> 
> Do not add the new text. Instead, replace
> 
> 	"The value of a property when expressed in XML MUST be well
formed."
> 
> by
> 
> 	"The value of a property element formally consists of the
following
> items
> defined in [XMLINFOSET], chapter 2.2:
> 
> -	Child element and character information items (element and text
> content),
> -	Attributes,
> -	Namespace attributes (as far as used by child information items)
> -	In-scope namespaces (as far as used by child information items)
> -	The value of an xml:lang attribute if in scope of the property
> element."

1) What is XMLINFOSET? 
2) This definition of a property value adds significant definitions to
the specification. Are the implications of each of these consistent with
existing implementations?

> Section 4.2: Lock-null resources removed
> 
> Text mentions: "SHOULD default to reasonable, or reasonably blank,
values
> for other properties like getcontentlanguage"
> 
> I disagree: unknown properties should be treated as not being present
> (just
> like the relevant HTTP headers), NOT as blank.

Any reasons? Any suggested text?  Is it OK for these particular
properties to be not present?

> Section 4.5: Propertybehavior (in MOVE, COPY) removed
> 
> Quote: "Live properties described in this document SHOULD be
duplicated as
> identically behaving live properties at the destination resource.  If
a
> property cannot be copied live, then its value MUST be duplicated,
> octet-for-octet, in an identically named, dead property on the
destination
> resource. "
> 
> Comments:
> 
> 1) did we reach consensus on this?
We did reach consensus on removing propertybehavior, IMO. I attempted to
turn the vague idea into text. This particular text existed before, by
the way so is in some sense a different issue.

> 2) If we did, the wording "octet-by-octet" doesn't make sense (because
> we're
> talking of property values)
You may be right. Do you have another suggestion?

Lisa

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 4 Jul 2002 08:31:54 +0200

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Wednesday, July 03, 2002 11:27 PM
> To: [email-masked]
> Subject: RE: New RFC2518bis draft
>
>
>

Geoff:
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0318.html>

> > -	The value of an xml:lang attribute if in scope of the property

<http://www.w3.org/TR/xml-infoset/>

> existing implementations?

It adds definitions where the spec used to be silent. I think this is a good
thing. What may be controversial is the requirement to persist attributes
attached to the property element itself, but AFAIK this is supported both in
IIS and moddav (will have to check).

> properties to be not present?

The reason is that "being blank" is *different* from "not being present".
This is something we need to sort out for all resources, not only the
formerly lock-null-resources. So the text *here* probably shouldn't say
anything at all, and then we should clarify which DAV: properties are really
required.

Please do not require to report "reasonable defaults" for things like the
content type when the server doesn't know. That would break HTTP.

> We did reach consensus on removing propertybehavior, IMO. I attempted to

Correct.

> the way so is in some sense a different issue.

Maybe MOVE and COPY need to be treated differently. If a server can't move a
resource with it's live properties staying alive, I'd claim that it actually
can't move the resource at all, and thus MOVE should fail (requiring the
client to fall back to COPY/DELETE).

Opinions?

> You may be right. Do you have another suggestion?

Just remove it. "Duplicating" a property value is well-defined, as long as
the "property value" is well-defined (which we're trying to fix).

Julian