RE: rfc2518-bis-04 issues (part 1)

> From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
> Behalf Of Elias Sinderson
> Sent: Wednesday, July 30, 2003 10:48 PM
> To: w3c-dist-auth@w3.org
> Subject: Re: rfc2518-bis-04 issues (part 1)
>
>
> Comments inlined below...
>
> Cheers,
> Elias
>
>
> ...
>
> My feeling is that while a server is allowed to rewrite XML as long as it
> preserves the semantics, dropping namespace prefixes is likely to cause
> problems. For example:
>
> Storing
> <Foo:bar>
> </Foo:bar>
> as
> <Foo:bar/>
> to save space is perfectly fine, while storing the above as
> <bar/>
> is not. The issue at hand is that namespaces serve to qualify the semantic
> interpretation of a given XML element, hence dropping that
> qualification can
> only lead to interoperability problems between clients which respect or,
> alternately, expect namespaces. Without the namespace qualifier, a client
> may not be able to know what is meant by an element. I would be happy to
> construct a more meaningful example to illustrate this, but I
> hope the above
> is sufficient. This is an important issue that we need to reach a
> concensus
> on.

It get's worse. Consider

<D:prop xmlns:E="whatever"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:xs="http://www.w3.org/2001/XMLSchema"><E:foo><E:bar
xsi:type="xs:boolean">true</E:bar></D:prop>

Not storing the namespace mapping for "xs" will simply break the content,
even if the prefix isn't used for any child element.

> ...
>
> > 03-C17:
> >
> > 8.1.5.: "Because clients may be forced to prompt users or throw away
> changed
> > content if the ETag changes, a WebDAV server MUST not change
> the  ETag (or
> > getlastmodified value) for a resource when only its property values
> change."
> >
> > Some servers do, and I don't think we can change that. Therefore I think
> > this change at least needs explicit consensus on the mailing list.
>
> I vote for the wording that is in there.  I think we've already reached
> consensus that changing property values should not be changing etags.

Where and when?

> I also believe that there was already concensus re: property values not
> affecting ETags... Since doing a PUT of a resource doesn't affect
> properties
> and a GET doesn't retrieve properties, the ETag should not change when
> properties on a resource do. That is to say that ETags should only be

That's simply not true. You're argueing from a world view where the server
stores properties and content as separate entities. However, it's perfectly
legal to have a server that

- extracts some properties upon PUT (for instance metadata from a WORD
document) and/or
- changes the content upon PROPPATCH of one of the aforementioned
properties.

I think that we can't and shouldn't make this behaviour illegal.

> modified when the enitity, itself, is modified (hence the name
> entity tag).
> We may want to consider, however, introducing an equivalent
> property tag, or
> PTag, which could be used to determine if properties on a given resource
> have changed. An argument with a (set of) use case(s) would have to be
> developed to make this a compelling idea.

Yes, but that's a separate discussion.

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Wednesday, 30 July 2003 17:16:59 UTC