Re: Access-Control: Proposed restructuring

On Wed, 16 Jan 2008, David Orchard wrote:
>
> Stuart Williams and I made comments about restructing the Access 
> Control spec, and we took an action item to craft up a proposal.  A 
> rough first version is ready to look at, at 
> http://dev.w3.org/2006/waf/access-control/Overview-Declarative-20080116. 
> html
>  
> The highlights:
> - Redid the protocol to be top-down rather than bottom-up
> - Redid the algorithms to use pseudo code.
> - Converted most of the EBNF to ABNF.

Given that this is a purely editorial matter, I'd rather we just left this 
exlusively up to the editor of the specification, lest we fall into a 
"design-by-committee" mindset where none of us take ultimate 
responsibility for the spec.

Having said that, I have to say that I prefer Anne's version. It seems 
much more down-to-earth from a readability persperctive. With the above 
version, I get much more of a feel of this being a theoretical document 
with too many unclear abstractions. I think with a document detailing a 
security model like this one, we need to stay as down-to-earth as 
possible.

Regarding changing english prose to pseudo-code, I fear that that is a 
serious step backwards. Pseudo-code does not have a normative definition 
and so it actually means that the above proposal doesn't technically 
define what the algorithm is. For example, the semantics of this line:

   if( scheme(item) != null && (scheme(item) != scheme (origin))

...are unclear. Does it mean to check that "the scheme of /item/ is 
neither null, nor the same as the scheme of /origin/", or does it mean to 
check that "the scheme of /item/ is not equal to the concatenation of the 
"null" string and the result of stringifying the result of comparing the 
scheme of /item/ to the scheme of /origin/"? Does "case-insensitive-match" 
mean two subtractions or is it one identifier? And so on. While we could 
define the semantics of the pseudo-code language, I think we are far 
better off, and far less likely to introduce errors, if we just stick to 
English prose, and avoid all indirection and abstraction. Again, this is a 
security-related spec, it is absolutely imperative that it be as clear and 
unambiguous as possible.

I think Anne has done a great job of this so far, and I don't think we 
should mess around with his work from an editorial standpoint.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 16 January 2008 20:28:47 UTC