Any open issues we want to try to close before
1 May publication?

Henry: The fact that we can't be
parallel to XSLT is what really bothers me. (Because we can't
have content.)

Norm: I think it's more likely
they'll be confused by using value when they meant select and
vice versa.

Some discussion of what errors users might
think are confusing.

Henry: select='div' is the
problem case, right? Consider using that in rename.
... Given that the majority of our users have not yet seen this
language, let's go for it.
... But make sure that we use the short form wherever possible
in the document.

Alessandro: Another concern is
that in many languages value holds an XPath expression, which
could be confusing.

Henry: So that's also in favor of
getting rid of value?

Alessandro: Yes, I think so.

Norm: Is there anyone who has
reservations about losing value?

Vojtech: If we get rid of value,
then we would need to fix a lot of strings in the standard
library.

Mohamed: I think the main problem
was that if we use select, then we'll get non-string results
from some expressions.

Norm: I'm still on the fence, but
I see that there are more issues.

Henry: And you don't get the
short-form workaround for p:variable, which is the first
example of value= in the spec.

Norm: Maybe we should ask.

Henry: I think we should *do it*
and then ask. So that users can see the consequences.

Mohamed: I think we're opening a
door we tried to close, about leaving all the type of value and
option as string. Now we'll have the type from XPath 1.0 or 2.0
and we'll have to deal with that.

Norm: I think that's true even if
we leave value= in.

Henry: It's slightly odd that for
boolean valued options you can either write select="'true'" or
select="true()"
... What you can't write is select="'true()'" or
select="true".

Norm: Right. But that's the same
in XSLT.

Proposal: Ditch value= and make
it clear in SoTD that we're open to reintroducing it if there's
pressure.

(And subject to the editor's ability to do
this before 1 May)

Accepted.

Parameter input ports

Norm attempts to describe the status quo.

Norm: Should we treat this like
our value= decision and remove it now, asking the users if they
have problems with that.

Proposed: Pull out the magic,
note it in the SoTD.

Accepted.

Add @fail-on-error to
p:for-each/p:viewport

Norm attempts to describe the situation raised
by James Fuller.

Mohamed: I asked for something
like this for rename a few months ago. So you can tell if it
did some renaming.
... I think if we do it for for-each, we should do it for other
steps as well.

Alessandro: Another way to look
at is to use an XPath 2.0 treat as expression.
... match="chapter treat as element()+"

Norm: Interesting.
... I think on balance, I'd rather not given the analsys that
would be required to find other steps where it made sense.

Henry: I'm in favor of the status
quo.

Proposed: Not for V1.

Accepted.

Empty document node vs. undefined context.

Norm: More consistent with XPath
2.0.

Mohamed: What's the consequence
for someone converting from XPath 1.0 to XPath 2.0?

Norm: That expressions that
relied on the empty context node will now be errors: fix your
expressions.

Mohamed: I'm ok with it.

Alessandro: I agree too.

Proposed: In XPath 2.0
implementations, make the default context node undefined in
those places where it's currently an empty document node.

Accepted.

Any other business?

Some discussion of future meetings; Norm will
have to give regrets for 15 May and 22 May, Henry will
chair.