EXPath meeting - some notes

Gentlefolk,

I won't be able to attend the EXPath meeting in Prague, but offer the 
following two issues/suggestions that you may care to discuss.


    1. Standard models for Options/Parameters/Properties

During the work on Binary, and especially on the proposed Archive, one 
of the issues that arose was what model should be used for reporting 
multiple properties or defining options in calls, as opposed to main 
data arguments or results. There were a number of possibilities open, 
some more convenient and complete than others, but issues of backwards 
compatibility, particularly between Xxxxx2.0 and Xxxx3.0 versions were 
raised. These notes mainly discuss describing /options/, as the problem 
is most acute there, but similar issues can arrive from properties.

Broadly speaking the issue is how to describe a partial /set/ of option 
values within a single argument of a function call, e.g.

    arch:create($entries as xs:string*,
    $new as xs:base64Binary*,
        $options as ????)

In some cases, such as |bin:decode-string|(|$in|| as 
||xs:base64Binary?|, |$encoding|| as ||xs:string|), only a single option 
makes sense, but in the more complex, such as arch:create(), there can 
be a significant number of control options available (e.g. 
last-modified-date, encoding, overwrite, compression....) which have 
sensible defaults.

Possible representations for such sets of options could include:

  * An XML element tree with option name/values as children (but please
    NOT with children <property name="/nnnn" /value="/vvvvv/"/>). [This
    has utility when character encoding 'maps' might be needed
  * A set of name/value XML attributes, either as a sequence, or
    attached to a (dummy) parent element.
  * A named property map, described as a (possibly typed) XPath map.

In various areas of the XML space we have experience with such a variety 
of representations - some are very awkward, some simple, some highly 
general. From Saxonica's point of view, the last, using the XPath3.0 map 
type, is the most general, as it allows values of many different types 
(including other maps of course), and points to the future, but of 
course it does limit to 3.0+ implementations. However, we feel very 
strongly that discounting the map on the basis of backwards 
compatibility would be a significant drawback to utilising EXPath 
standardisation work in future high-performance and 
high-coding-productivity implementations.

We managed to produce a simple standard form for EXPath error codes. I'd 
very much like the EXPath meeting to discuss some of the possibilities 
of producing at most a couple of EXPath standard models for describing 
options and reporting multiple-properties. Then I think we could suggest 
that a conforming implementation for EXPath ZZZ module was required to 
support at least one of the standard models, but could elect to support 
more than one.


    2. XParse Module

As a part of my work on developing a stremability analysis tool last 
year I got involved in parsing XPath to XML parse trees, for subsequent 
analysis though XSLT. There wasn't a standard model for doing this, 
though I use Gunther Rademacher's REx (http://www.bottlecaps.de/rex/) 
parser generator to great effect. Even then there has to be some 
post-processing to make the enormous parse trees usable, or at least 
readable. This then suggested that a standard model for invoking such 
parsing (and the reversal) might be of some utility (and a good target 
for XSLT packages....) So you'll find attached the beginnings of a 
possible module definition, which of course needs a lot more work.  
Please feel free to discuss it. In free time (when not writing for XML 
London or Balisage, or working on vital Saxonica stuff!) I'll probably 
push this a it further, but if anyone else wants to contribute....



Do have a good meeting and let me know what happened.

John

-- 
*John Lumley* MA PhD CEng FIEE
john@saxonica.com <mailto:john@saxonica.com>
on behalf of Saxonica Ltd