Re: Slight inconvenience of using only @select for options

/ Innovimax SARL <innovimax@gmail.com> was heard to say:
| But I must admit that it does not solve the problem when you want to do that
| for parameter or when you just want to use non contextual XPath ("$option",
| "2+2",)

The 2+2 example (assuming you mean for the result to be "4" :-) has to
use select so it's no different now that we've removed @value.

AFAICT, the only cases that have changed are simple literal strings,
for which you can use the shortcut syntax.

I *am* sympathetic to the fact that expressions like this:

  select="$foo"
  select="p:system-property('p:language')"

are problematic wrt context, but they aren't any different now then
they were before we removed @value.

If we leave things as they are, then:

  select="count(//p)"
  select="resolve-uri('foo')"
  select="/*/@role"

all work as expected. That is, they rely on the default binding for
the context and (we assume) that's what users will most often want.

So you have to say:

  <p:option name="whatever" select="p:system-property('p:language')">
    <p:empty/>
  </p:option>

if the context might be a sequence. OTOH, if we make the default an
empty document or unbound context, then for the latter examples,
you have to say:

  <p:option name="whatever" select="resolve-uri('foo')">
    <p:pipe step="somestep" port="someport"/>
  </p:option>

And if the step contributing the otherwise primary input port doesn't
have a name, you have to give it one.

On balance, I think I'd prefer to have to insert <p:empty/>
occasionally if we can't do better.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Consistency requires you to be as
http://nwalsh.com/            | ignorant today as you were a year
                              | ago.--Bernard Berenson