W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > May 2012

Of parameters, maps, and variables

From: Norman Walsh <ndw@nwalsh.com>
Date: Wed, 23 May 2012 07:33:24 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2likjf7y3.fsf@nwalsh.com>
Hello world,

I still feel that maps offer a way forward to simplifying parameters
without sacrificing flexibility. (I say "feel" because I haven't been
able to articulate a clear proposal yet.)

Trouble is, changing the value associated with a key in a map is a
side effect. Unless the only way to do that is with a first-class
step, we don't have a story about the order in which the expressions
will be evaluated.

And even if the only way to do it is with a first-class step, we'll
still have the problem of expressing dependencies among those steps
(since they're not likely to have outputs that are consumed).

I think we're going to have to make implementors work harder. I think
implementors are going to have to do static analysis on expressions
and use variable def/use when calculating the order of evaluation.

This will have the pleasant consequence that it will be ok to put
p:variable anywhere in the pipeline instead of requiring users to
create a new p:group just to allow a variable definition at the top of
that group.

The only gaping hole I see is what to do about instructions that
don't have a clear order:

  <p:set-param map="mymap" name="key" value="{2+3}"/>
  <p:set-param map="mymap" name="key" value="{3+4}"/>

I guess we use document order to disambiguate those. So the value
of the key in mymap is 7, not 5.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
Lead Engineer
MarkLogic Corporation
Phone: +1 413 624 6676
www.marklogic.com

Received on Wednesday, 23 May 2012 11:34:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 23 May 2012 11:34:22 GMT