Current Desktop capabilities - take 3.

Dave Cridland [Home] dave at
Thu Jun 3 22:05:03 EEST 2004

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:


... and:


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?


More information about the xdg mailing list