RE: New RFC2518bis draft

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Wednesday, July 03, 2002 11:27 PM
> To: w3c-dist-auth@w3c.org
> Subject: RE: New RFC2518bis draft
>
>
>
> 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.

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

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

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

> 2) This definition of a property value adds significant definitions to
> the specification. Are the implications of each of these consistent with
> 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).

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

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.

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

Correct.

> turn the vague idea into text. This particular text existed before, by
> 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?

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

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

Received on Thursday, 4 July 2002 02:32:21 UTC