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

Re: Options *again*

From: Jeni Tennison <jeni@jenitennison.com>
Date: Mon, 19 May 2008 15:59:31 +0100
Cc: public-xml-processing-model-wg@w3.org
Message-Id: <FA6CFF48-A262-4DBF-80CD-D42B3912F2C7@jenitennison.com>
To: Norman Walsh <ndw@nwalsh.com>


> 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*).

No no no. You can't use the namespace declarations from the step  
instance! That would make things crazily hard to debug: authors of  
pipelines would have to write "and to get this option to default  
correctly, you must make sure you have the prefix x bound to the  
namespace y". It's just horrible.

What about relaxing the rule "The variable bindings consist only of  
bindings for options whose declaration precedes the p:option itself in  
the surrounding step signature;" such that all the options declared on  
the step are available. That would solve the implementation problem,  

Otherwise, it's not hard to come up with a regular expression to  
extract the variable references within an XPath (I know I've done it  
before; ping me if you need me to recreate it), and then check  
statically whether any of the references are to options that are  
declared after the one you're looking at. If you've done that check  
statically, you don't have to worry about passing in extra variable  
bindings because you know they won't be used.


Jeni Tennison
Received on Monday, 19 May 2008 15:00:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:46 UTC