xml-dev - improved writing ...

[Arnaud Sahuguet <sahuguet@gradient.cis.upenn.edu>]

Hi, 

I have been following the discussion about the "improved writing"
issue and I agree with most of the comments.  I have been working on
an implementation of a new query language for XML (Kweelt:
http://db.cis.upenn.edu/Kweelt/) and this meant to read and understand
specs such as XPath, XSLT, namespaces and XML-Schemas.

The first comment I have to make is that the specs are ALWAYS skipping
the big picture.  Why do we need this new spec?  How does this new
spec fit in the current state of things?  Also, explaining the
rationale behind decisions would be useful.

The second comment is that the specs want to appear formal when they
are semi-formal at best. In most cases, the reader gets drowned in
pointless syntactic details while crucial ones are put under the rug.
If one wants to be formal, one should use the right formalism. In most
cases, English (or any so-called natural language) is not appropriate,
because it is ambiguous or subject to various interpretations.

Just as an example, for XPath and XSL-T, look at the descrption by
Phil Wadler.  The description uses denotational semantics to describe
the behavior of both languages.
http://www.cs.bell-labs.com/who/wadler/topics/xml.html#xsl-semantics
(*) A formal semantics of patterns in XSLT (to be read first)
(*) Two semantics of XPath

Some people will complain that one needs to understand mathematics to
read these two descriptions.  If this is the price to pay to have a
description that can be understood unambiguously, let us
pay for it. And don't get scared by the formalism and the mathematical
symbols. This is just syntax :-)
In a "A formal semantics of patterns in XSLT" the author gives a
user-friendly tutorial about the formalism used. See for yourself.

I can tell you as a developer, that the translation from denational
semantics to code (Java code in my case) is straight-forward. The
semantics already captures the right abstractions.  This formalism not
only provides a non-ambigous description of the what the language
should do, it also makes the job of implementing it much easier.

Regards,

Arnaud Sahuguet,
PhD candidate (Database Research Group, Univ. of Pennsylvania)
CTO Tropea Inc.