RE: HOW_TO_IDENTIFY_LOCK_OWNER

Interesting idea.

However:

1) Let's assume that we adopt something along the line the
DAV:contact-URI-set I proposed earlier, but put it *into* the existing
DAV:owner element. We would just define that if a DAV:owner contains
DAV:contact-URI-set, it's format must adhere to our "DTD".

2) Existing clients which do not add DAV:contact-URI-set aren't affected at
all.

3) When will existing clients use DAV:contact-URI-set? I'd say never,
because I just thought of this property name :-), and they shouldn't anyway
because it's an element in the DAV: namespace (which is reserved for
official WebDAV stuff).

4) The main problem will be new (updated) clients that want to support the
new feature, while maintaining compatibility with old versions. The cleanest
way would be not to interfere with the old element. Old stuff stays in
DAV:lockinfo/DAV:owner, new stuff is put into
DAV:lockinfo/DAV:contact-URI-set.

5) To find out whether 4) is a problem, we would have to check all existing
clients that have the problem of assuming some specific format. MS Office (I
think) always displays the concatenated text content of all text nodes, so
it would still display something useful, however it might not look pretty.

Julian



> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of gclemm@rational.com
> Sent: Monday, January 28, 2002 7:06 PM
> To: w3c-dist-auth@w3c.org
> Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER
>
>
> It probably is worth looking a bit harder at what exactly would be
> the costs of simply recommending some standard elements to go into
> the value of the existing DAV:owner element.
>
> I assume that clients today are written to work really well when they
> encounter a lock written by clients from the same vendor (since they
> would have a detailed knowledge
> of the structure of the information in DAV:owner), but at least
> "blurt out" the information in DAV:owner when encountering a
> lock from some other vendor's client.
>
> If we were to recommend some specific sub-elements for DAV:owner,
> then existing clients would be unaffected when running against
> existing servers (of course), and new clients would exhibit the
> desired improved interoperability when running against new servers.
>
> It is only old clients from a given vendor running against new
> servers from the same vendor that would see a hit, if the new
> standardized DAV:owner fields can't be inserted without disrupting
> the ability of old clients extracting the old information.
>
> In particular, since it is the new *clients* that will
> be inserting these new fields, if we make sure that the
> location of the new standard fields is sufficiently flexible,
> then the new clients from a specific vendor
> might be able to append these new fields to the
> information they currently write in a way
> that won't disrupt the ability from old clients *from that vendor*
> being able to read the old information.
>
> So it might be worthwhile to first find out
> if there is some way we could define the
> location of the new fields such that new clients from a vendor could
> can add them in without disrupting the behavior of their old clients.
>
> If there really is no way to do this, then we could add a second
> DAV:formatted:owner field instead.
>
> Cheers,
> Geoff
>
>
>
> -----Original Message-----
> From: Lisa Dusseault [mailto:lisa@xythos.com]
> Sent: Monday, January 28, 2002 12:34 PM
> To: Jason Crawford; Daniel Brotsky
> Cc: Clemm, Geoff; w3c-dist-auth@w3c.org; Julian Reschke
> Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER
>
>
>
> > Geoff, Julian, are we sure we can't just define DAV:owner (rather than a
> > new field) more restrictively to comply with your Julian's proposal?
>
> We can't redefine DAV: owner.  As you suggest, there are current deployed
> uses of DAV:owner and there would indeed be transition issues.
>
> > Lisa, Geoff, Julian, Can you think out the interoperability
> scenarios and
> > issues of Julian's proposal?  (I wasn't at the interops so I'm
> > not familiar
> > with the current uses of DAV:owner and how Julian's proposal affects the
> > currently deployed systems and if there are transition issues.)
>
> Lisa
>

Received on Monday, 28 January 2002 13:30:11 UTC