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

Options *again*

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 15 May 2008 08:43:58 +0100
To: public-xml-processing-model-wg@w3.org
Message-ID: <m24p90nha9.fsf@nwalsh.com>
We say two things about option default values:

1. "The select expression is only evaluated when its actual value is
needed by an instance of the step type being declared."

2. "The variable bindings consist only of bindings for options whose
declaration precedes the p:option itself in the surrounding step
signature;"

I'm pretty sure I was in favor of point 1 so that this declaration:

<p:declare-step type="px:example">
  <p:option name="foo" select="1"/>
  <p:option name="bar" select="$foo"/>
...
</p:declare-step>

and this instance:

<px:example foo="5"/>

would function as if it had been written like this:

<px:example foo="5" bar="5"/>

I'm still in favor of these semantics. However, I'm finding it a little
difficult to implement point 2. Here are some things that don't work:

- You can't evaluate the select expression when you see it in the
  declaration because that doesn't give you the semantics of point 1.

- You can't simply wait until you need it and then blindly evaluated it
  because the in-scope options may include more than point 2 allows.

- You can't test the variable references by evaluating the select
  expression when you see it in the declaration because missing values
  might cause type exceptions.

AFAICT, you either have to parse the expression to find the variable
references or you have to construct a different dynamic context just
for the evaluation of the default value.

Now that we've got both p:option and p:with-option, I wonder if a
simpler solution would be sufficient.

First, rename 'select' on p:option to 'default'. Then say that if a
step instance does not provide an explicit value for an option, and
that option has a @default in the declaration for that step type, the
value of the @default is evaluated as an XPath expression in the
context of the step instance (with an empty context node and the 
in-scope namespaces *of the step instance*).

This provides the semantics of point 1 but relieves the implementation
From special rules for evaluating the expression. It will allow step
authors to write funky, context-sensitive defaults, but since the
attribute is no longer spelled 'select', I think I can live with that.

Thoughts?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Klein bottle for rent; enquire within.
http://nwalsh.com/            | 

Received on Sunday, 18 May 2008 19:59:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 18 May 2008 19:59:42 GMT