Current Desktop capabilities - take 3.
Dave Cridland [Home]
dave at cridland.net
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'
> > '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
> ASCII, or does it include the extended 8-bit ASCII accented
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:
would be parsed equally by a base-level compliant parser.)
I can live with case-sensitivity, but in such cases I prefer
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
More information about the xdg