RE: more v5 draft questions

[Note to readers: Please read, there are some proposals below]

>8.11.5 has the Depth value "infinity" written as "Infinity".  Should be
>lower case

fixed

>Sometimes the opaquelocktoken scheme is written in all lower case (8.13.10)
>and sometimes in mixed case (8.12.5)

fixed

>Also 8.13.10 writes the locktoken "directly", rather than as a Coded-URL,
>as mandated by 9.11

fixed

>Perhaps it would be useful to move the definition of Coded-URL from 9.5
>Destroy Header to someplace more generic, since it is used in many places
>(e.g. Enforce-Live-Properties, Lock-Token request and response headers etc)

Traditionally the way such definitions are handled is by defining them at
their first use. That's why when we use the URI production we only give a
reference on its first use. This all having been said, so the hell what? I
will add a section on generic BNF productions.

>Why is Coded-URL not used in the "AdditionalLocks" portion of the Lock-Info
>request header (unless that's because AdditionalLocks is to be dropped, as
>I suspect?)

Damn your good! You wrote this before I wrote my proposal.

>Finally, can someone explain to me why we need "Coded-URL"?  Why can't we
>just write property names as property names?  We don't seem to need to code
>the URI in the Destination header, so why do we need to code it when used
>in e.g. Enforce-Live-Properties, or for a list of locks?

See Jim's explanation, he covers all the basis. I do agree about encoding
lock-token on responses which are singletons. The only reason it uses a
coded-URL is to make it symmetric with the lock-token request header. In
fact I will make the lock-token response a #coded-url. There is no reason
the server couldn't return multiple identifiers for a single lock, the
client need only remember one. I have added the following language to the
response lock-token header:

	If multiple lock-tokens are returned then they MUST all refer to the
exact same lock.  As the lock tokens all refer to the exact same lock a
client need only record one of them.

>To take this from a slightly different angle, when a property name is
>written as a coded-URL, it looks just the same as if if were an XML open
>tag.  Would it be better to express them as "empty" tags instead?  The
>difference is that <foo><bar><quux> is not legal XML, but
><foo/><bar/></quux/> is.  Another advantage, although unlikely to arise in
>practise is that XML allows for tags to have arbitrary attibutes, e.g. I
>could have  <foo type="3"/>.  Here, the "property name" is just foo.  so
>there's a real difference, I think, between expressing this is a coded-URL
>of the property name as opposed to as a tag.

Ditto Jim, I don't think this is an issue.

			Yaron

> -----Original Message-----
> From:	Jim Davis [SMTP:jdavis@parc.xerox.com]
> Sent:	Tuesday, December 16, 1997 5:30 PM
> To:	w3c-dist-auth@w3.org
> Subject:	more v5 draft questions
> 
> 8.11.5 has the Depth value "infinity" written as "Infinity".  Should be
> lower case
> 
> Sometimes the opaquelocktoken scheme is written in all lower case
> (8.13.10)
> and sometimes in mixed case (8.12.5)
> 
> Also 8.13.10 writes the locktoken "directly", rather than as a Coded-URL,
> as mandated by 9.11   
> 
> Perhaps it would be useful to move the definition of Coded-URL from 9.5
> Destroy Header to someplace more generic, since it is used in many places
> (e.g. Enforce-Live-Properties, Lock-Token request and response headers
> etc)
> 
> Why is Coded-URL not used in the "AdditionalLocks" portion of the
> Lock-Info
> request header (unless that's because AdditionalLocks is to be dropped, as
> I suspect?)
> 
> Finally, can someone explain to me why we need "Coded-URL"?  Why can't we
> just write property names as property names?  We don't seem to need to
> code
> the URI in the Destination header, so why do we need to code it when used
> in e.g. Enforce-Live-Properties, or for a list of locks?
> 
> To take this from a slightly different angle, when a property name is
> written as a coded-URL, it looks just the same as if if were an XML open
> tag.  Would it be better to express them as "empty" tags instead?  The
> difference is that <foo><bar><quux> is not legal XML, but
> <foo/><bar/></quux/> is.  Another advantage, although unlikely to arise in
> practise is that XML allows for tags to have arbitrary attibutes, e.g. I
> could have  <foo type="3"/>.  Here, the "property name" is just foo.  so
> there's a real difference, I think, between expressing this is a coded-URL
> of the property name as opposed to as a tag.
>

Received on Tuesday, 30 December 1997 01:39:34 UTC