- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Mon, 19 May 2008 15:59:31 +0100
- To: Norman Walsh <ndw@nwalsh.com>
- Cc: public-xml-processing-model-wg@w3.org
Norm, > > 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, right? 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. Cheers, Jeni -- Jeni Tennison http://www.jenitennison.com
Received on Monday, 19 May 2008 15:00:10 UTC