[Xcb] XML description of XKB optional fields

[Jamey Sharp]

We've had a to-do item for a while to implement the XKB extension (bug
#6684). Vincent Torri tried to do this in April 2005, but XKB does some
strange things and he moved on to more productive tasks. :-) I think we
can express almost all of XKB in our current XML tagset, and I'm hoping
somebody will volunteer to give it a try.

XKB presents two major challenges: Some fields are optional, conditional
on the values of other fields; and some lists have a length that depends
in complicated ways on a bitfield, and elements of varying types. I
think these are both essentially the same problem, and we can express
all these cases as lists of either 0 or 1 element.

One of the two optional fields is described this way:

1	m			nMapEntries
1	BOOL			hasPreserve
...
[4m]	LISTofKB_MODDEF 	preserve

Because BOOL values are required to be either 0 or 1, we can represent
that this way in our XML:

<field type="CARD8" name="map_entries_len" />
<field type="BOOL" name="has_preserve" />
<list type="KB_MODDEF">
	<op op="*">
		<fieldref>map_entries_len</fieldref>
		<fieldref>has_preserve</fieldref>
	</op>
</list>

That wasn't too bad. Now for the really ugly.

2	SETofKB_GBNDETAILMASK		reported
V	LISTofITEMs			replies
	(if this in reported:)		(then this field is present:)
	XkbGBN_Types			map
	XkbGBN_CompatMap		compat
	XkbGBN_ClientSymbols		map
	XkbGBN_ServerSymbols		map
	XkbGBN_IndicatorMap		indicators
	XkbGBN_KeyNames 		names
	XkbGBN_OtherNames		names
	XkbGBN_Geometry 		geometry
ITEMs
M	XkbGetMap reply 		map
C	XkbGetCompatMap reply		compat
I	XkbGetIndicatorMap reply	indicators
N	XkbGetNames reply		names
G	XkbGetGeometry reply		geometry

Given some extensions of the XML, we can encode that this way:

<field type="CARD16" name="reported" />
<list type="reply:GetMap" name="map">
	<op op="&amp;">
		<value>1</value>
		<op op="|">
			<fieldref>reported</fieldref>
			<op op="&gt;&gt;">
				<fieldref>reported</fieldref>
				<value>2</value>
			</op>
			<op op="&gt;&gt;">
				<fieldref>reported</fieldref>
				<value>3</value>
			</op>
		</op>
	</op>
</list>
<list type="reply:GetCompatMap" name="compat">
	<op op="&amp;">
		<value>1</value>
		<op op="&gt;&gt;">
			<fieldref>reported</fieldref>
			<value>1</value>
		</op>
	</op>
</list>
...

...Phew, I'm tired of typing already. But perhaps you get the idea.

Now, it isn't too big of a deal to make the XSLT support right-shift and
bitwise-or operators, in addition to the current left-shift and
bitwise-and. Adding the ability to refer to a reply as a field type also
isn't that hard, since fortunately we're already generating iterators
for them. I can see that a couple more extensions will be needed along
the way, but I have ideas for those too. Typing all this in is
time-consuming, but manageable.

Will somebody either go give it a try, or put forward a better proposal?

--Jamey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/xcb/attachments/20061129/e2150032/attachment.pgp