Re: Composability

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeni Tennison writes:

> Norman Walsh wrote:
>> / Jeni Tennison <jeni@jenitennison.com> was heard to say:
>> [...]
>> | and call this new pipeline in the same way as before:
>> |
>> |   <my:matching-documents xmlns:my="http://www.example.com/ns/jeni">
>> |     <p:option name="test" value="/my:foo[@bar = $bar]" />
>> |   </my:matching-documents>
>> |
>> | The value '/my:foo[@bar = $bar]' is passed as the value of the test
>> | option to <jt:matching-documents> as a string. But in my pipeline,
>> | where <p:matching-documents> is called, there's no binding for the
>> | 'my' prefix, nor for the $bar in-scope option, so the pipeline fails.
>> Perhaps we should allow options to be passed into called
>> pipelines. At
>> the moment, it's only forbidden by the special rules for constructing
>> the p:pipeline environment. We could fix that.
>> Then, if $bar is in scope for the pipeline that calls
>> my:matching-documents, it would be in scope for the step that
>> evaluates it. Options would be passed down.
>
> But then they shouldn't be options. The distinguishing feature of
> options is that they are predefined, and if you're passing in name/value
> pairs from the calling pipeline, then those pairs can't be known in advance.

I'm not clear why that's at issue here.  We're talking about the
availability of option _bindings_ for discharging variable references
in XPaths, for which we've already established that all in-scope
option bindings are available.  The only question is, should named
pipelines be different from other steps in what constitutes the
in-scope bindings.  I agree with Norm that I can't see any reason why
there should be a difference, so the '$bar' part of your example
should work just fine.

Namespaces are a different question, but my _inclination_ is to say
that we should at least consider what is from the _user_ perspective a
very simple statement: prefixes in XPath expressions in attribute
values in XProc pipeline documents are expanded wrt the namespace
bindings of their parent EII.  What implementations have to do to
achieve this is their problem.  At first blush, doesn't seem too bad
to me -- options whose values are XPaths (oops, here comes option
value typing again :-) have to carry their namespace binding context
with them.

ht
- -- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFGZsm3kjnJixAXWBoRAn3wAJ9okncKVMgh3uGwGwWe754dgyLmAgCeIfP+
x3QfCxbNZQ8U+ddDSiaQ0fM=
=7UHX
-----END PGP SIGNATURE-----

Received on Wednesday, 6 June 2007 14:50:54 UTC