W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2003

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 30 Jul 2003 23:16:20 +0200
To: <w3c-dist-auth@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCAEFHIAAA.julian.reschke@gmx.de>

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

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

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.


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Wednesday, 30 July 2003 17:16:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:29 UTC