Re: Variables/Parameters and Scoping

/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| 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.

Indeed. I'm not trying to bias things in favor of simplicity of
implementation at the expense of usability (well, at least I don't
think I am :-).

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

FWIW, I'm not sure I see that as a practical implementation strategy,
I was just trying to emphasize the fact that "XPath over a single
document" is a discrete bit of functionality (both in terms of
implementation and explanation to users) that's well defined.

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

Sure, I see that. In fact, in my own implementation it'll be
more-or-less trivial to implement what you suggest. :-)

One concern I have is that XSLT, as a host language for XPath, can
reasonable be expected (is, in fact, expected) to have all of the
documents that it uses in memory. There's clear value in being able to
shove documents through a pipeline that are bigger than practical
memory limitations would allow one to load directly in XSLT.

But maybe that's no more than an implementation detail.

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

Absolutely. The question is, how much of the pipeline's internal state
do we need to expose in the evaluation context? I'm just determined to
make us consider every decision in terms of what is the simplest thing
that could work.

| [1] http://www.w3.org/TR/xpath#section-Introduction
| [2] http://www.w3.org/TR/xslt#section-Expressions

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.