XStandards

Introduction

This wiki was setup to track some of the issues and discussions related to XStandards. When there is more content here, I will cross-link this page with the top-level Specifications page.

Many of these issues referenced here have had some discussion on the X.Org Foundation Architecture Task Force mailing list. This list is open to anyone who wishes to subscribe by going to the following location:

http://www.x.org/XOrg_Foundation_Join_OpenLists_New.html

Archives of this list are available at:

http://www.opengroup.org/sophocles/show_archive.tpl?listname=xorg_arch

Current issues

IPv6

One of the most recent issues under discussion has been the proposed updates to the necessary standards documents to include IPv6. Additional information on this process and all of the support documentation generated can be found on the "Proposed Enhancement to the X Window System for IPV6" page at:

http://www.x.org/IPV6_Review.html

The window for public comments on this topic closed on March 26, and no comments were received.

Shape Specification

A minor discrepancy has been found between the extension protocol opcodes for two requests in the SHAPE extension. This was filed in the following defect report:

http://freedesktop.org/cgi-bin/bugzilla/show_bug.cgi?id=282

The request ShapeInputSelected was listed as opcode 6, and the request ShapeGetRectangles was listed as opcode 7 in the specification, but they had opcodes 7 and 8 in the implementation. Given that the implementation has been around for years and that the current standards conformance tests will use the values defined in the header file (7 and 8), the specification document will be updated to use the values (7 and 8) as defined in the header file.

Additional information about this can be found in the following archives:

This issue is considered closed. The Open Group will check any standards documents they have generated to ensure that they don't need any updates as well.

Keysyms

Alan Coopersmith noted that some of the keysyms now defined in keysymdef.h conflict with what has been reserved for the vendor private range. These changes have been in existence for over three years, so they are essentially a de-facto standard. These keysyms were verified as fitting within some definition of the various language specifications for which they were intended to support.

Markus Kuhn has proposed that any character missing in the existing keysym table shall be encoded by adding 0x01000000 to the value of the character's Unicode position. This will make future extensions to keysymdef.h unnecessary. Markus is currently generating a patch to the protocol document to add another column to the tables that will contain the authoritative mapping to Unicode. This added text is in progress and will be posted here when available.

For more on keysyms and Unicode, see KeySyms.

Current mailing list archives on this topic can be found at the links below:

UTF8_STRING

Juliusz Chroboczek issued a proposal for the Inter-Client Exchange of Unicode Text. That original proposal can be found here:

http://www.pps.jussieu.fr/~jch/software/UTF8_STRING/UTF8_STRING.text

John McKernan issued a proposal (for discussion) with some modifications. That proposal can be found in the archives:

http://www.opengroup.org/sophocles/show_mail.tpl?source=L&listname=xorg_arch&id=44

John's rationale for the proposed modifications is that the standard should accept all valid Unicode UTF-8 characters, and that the standard should not specify a preference for some Unicode characters over others. A feeble attempt to generate a "diff" for the two proposals, along with additional explanatory information, can be found at:

http://www.freedesktop.org/~pma/XStandards/UTF8_STRING.revised.txt

Please note that *no* final decision has been made on the proposed revision, and that the topic is still under discussion.

Current discussion links on this topic can be found at the URLs below:

Future topics

There are some other minor standards inconsistencies that will be cleared up in the near future as well. Among them, the Xt C library specification for the function XtMakeGeometryRequest() includes a contradiction that needs to be corrected. In addition, the XKB C library specification for the functions XkbGetNamedIndicator() and XkbSetNamedIndicator() do not match the implementation. These topics will go through a public review process in the near future.

There are additional topics that will also be discussed in this forum. If you have issues you would like to see raised, please send them to Paul Anderson or join the X.Org Foundation Architecture Task Force mailing list referenced at the top of this document.

-- Main.PaulAnderson - 29 Mar 2004