Re: Variables/Parameters and Scoping

Hi Norm,

Norm Walsh wrote:
> My overriding concern is simplicity of design and implementation. I
> want the simplest thing that could possibly get the job done 80% of
> the time.

I guess I'm more concerned about usability than simplicity of 
implementation (there are relatively many users compared to 
implementers, and implementers only have to implement once, whereas 
users have to use all the time). Simplicity of design obviously helps 
both implementation and usage.

> I think evaluating an XPath expression over a single document is
> simpler. And I think it's all that's needed 80% of the time. And
> there's an obvious way to deal with the other 20%.
> 
> If we say that XPaths are evaluated in the context of a single
> document, then the XPath evaluator can be thought of as a little black
> box. You pass it a document and an expression and it returns
> something. (Granted, you have to replace variable and parameter
> references with their current literal values before you call the black
> box.)

Ahh, OK, it sounds as if we draw the lines around the XPath black box 
somewhat differently. I can quite understand why you'd find the 
suggestion of using variables to reference input documents complex if 
you think of it in terms of replacing variable references with literal 
values prior to passing the expression to the XPath black box.

I'm also thinking of the XPath evaluator as a black box, but I'm looking 
at setting the evaluation context for XPath as defined at [1]. In XPath 
1.0 the context consists of:

   * a node (the context node)
   * a pair of non-zero positive integers (the context position and the
     context size)
   * a set of variable bindings
   * a function library
   * the set of namespace declarations in scope for the expression

and:

   "The variable bindings consist of a mapping from variable names to
    variable values. The value of a variable is an object, which can be
    of any of the types that are possible for the value of an expression,
    and may also be of additional types not specified here."

So in my conception (and, I'd argue, the XPath specifications), the 
XPath black box accepts a bunch of name/value pairs as variable 
bindings, and all that we (as users of the XPath spec) have to worry 
about is what values get assigned to what names. The values can be 
anything, including document nodes (root nodes) and document sequences 
(node sets): they're not constrained to values that can be represented 
literally within the XPath expression.

> If we introduce a mechanism that allows XPath expressions to refer to
> multiple documents then the XPath evaluation has to be done by some
> part of the system that has much more intimate knowledge of the state
> of the pipeline execution, of the documents that are currently
> identified by labels, and how to get access to them.

I'll hold my hands up and admit that I'm one of the rare bods in this 
Working Group who *hasn't* actually implemented a pipeline engine. But 
at the *spec* level, I'm pretty sure that the right way to describe how 
we use XPath is to describe how the various parts of the evaluation 
context are set, in the same way as XSLT does with XPath [2]. The XPath 
evaluation engine doesn't need to know anything aside from the 
information provided in this evaluation context.

Cheers,

Jeni

[1] http://www.w3.org/TR/xpath#section-Introduction
[2] http://www.w3.org/TR/xslt#section-Expressions
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Wednesday, 24 May 2006 20:07:53 UTC