Known Issues in Limpid

Reverse Expressions in MatchedTemplates

SelectionManager has the task of finding a MatchedTemplate that best fits a node in a specific environment, using a embedded in the MatchedTemplate. This approach is robust and efficient but, if applied to a UnionExpression, it has both semantic and practical problems. Consider the expression string:

"ACT[2]/SCENE[1]/SPEECH[SPEAKER = 'HAMLET] | SPEECH[SPEAKER = 'OPHELIA']"

• How can we define the priority value of the expression?
• Is there a clean and efficent way to implement a reverse expression from unions? (I have not found one.)

The approach I have taken is to:

• Dissect the expression string by separating it at the bar '|' characters.
• Generate two or more separate MatchedTemplates and add them to the XSLResources under different keys corresponding to the separate subexpressions.

So what is the problem? It means that the method will break if confronted with a complex expression with a bar character deeply embedded in it, such as in a predicate. Not very likely, and there is always another way of expressing the predicate.

What is Missing?

Two fairly minor features were missing from XSLT:

• Result tree fragments are stiil not supported for variables and parameters. The concept is very dubious, messy to implement well and is missing from the XSLT 1.1 working draft and 2.0 recommendation. I consider it ancient history and not worth the trouble.
• Attribute minimization in HTML is now included, but irregularities like this give me good reason to prefer XHTML over HTML.

As far as I know, all of the DOM Level 2 (core), XPath 1.0 an other XSLT 1.0 recommendations are supported. Tell me if you do find something missing.

Overview of the Limpid Code

Very little is new in the overall system. The primary difference is in the addition of several parameters to Lexxia. The DOM code and supporting classes, such as the streams and DocumentBox, are more than six years old and continue to perform without problems. Even the XPath and XSLT code groups have survived for over three years without significant modification. So I believe that I can claim that the Limpid infrastructure is stable.

The port to Windows was essentially uneventful, with two small exceptions

• Writing to the console needs regular flushing;
• Passing of a char[] parameter does not reliably invoke automatic conversion to to const DOMString& if it can be interpreted as a boolean (as in OutputStream(...)). The boolean parameter is now explicit (as it should have been in the first place).
• The intrusion of carriage returns (char 13) into data was sometimes irritating, and lethal when processing LaTeX files. Because of multiple sources of characters here (files and string literals), there was occasional accumulation of multiple carriage returns in sequence, which were not visible in text editors. Writers and Readers now ignore carriage returns, but I/O at the byte level is not affected.

The present version of Limpid/Lexxia was developed on KDevelop 3.5.6-9.fc7, using a single (flat) source directory, rather than the structured source of earlier versions. This simplifies the inclusion of #include statements in the code, but complicates selection of cut-down versions of the library.