Current Desktop capabilities - take 3.

[Dave Cridland [Home]]

On Thu Jun  3 19:15:00 2004, Sean Middleditch wrote:
> On Thu, 2004-06-03 at 13:40, Michael Meeks wrote:
> 
> > 	Comments welcome, [ particulary the button descriptions - I'm
> > eager not to include 'gnome' or 'kde' in that string; is 'inset' 
> and
> > 'corner' adequate ? ]
> 
> "Element names must contain only lower-case alpha/numeric characters
> using the ASCII."
> 
> Yet several of the examples also include dashes.  Also, is that 
> 7-bit
> ASCII, or does it include the extended 8-bit ASCII accented 
> alphabetic
> characters?
> 
> 
You're right that it needs clarification, but ASCII is always 7-bit.

Anything 8-bit is some other charset - many of which (such as 
ISO-8859-1 and UTF-8) have all octet values <0x80 identical to ASCII.

I would expect identifiers within a protocol/specification to always 
be a subset of ASCII - printing characters only, case-insensitive if 
reasonably possible, starting with an alphabetic character.

It's generally useful to specify either '-' or '_' as being 
prohibited, ban '/' and '\', etc, so the identifier can be used with 
minimal, reversable, changes as a programming identifier and/or 
filename. Most protocols/specifications designate some sort of 
seperator character somewhere, and it's often useful to reserve 
another character explicitly for future extension (So the string:

foo;version=2.0

... and:

foo

would be parsed equally by a base-level compliant parser.)

I can live with case-sensitivity, but in such cases I prefer 
Michael's case-restriction.

My only mild concern is that each class of identifer does not have 
its own namespace. Is it possible to form them as 'tk-gtk', 
'button-inset', 'fs-gnome-vfs', etc instead? Might allow for 
expansion should we need it.

Michael, would you like me to write up some ABNF to describe the 
syntax fully?

Dave.