Kenneth Sklander, PicoForms
Blake Jones, ViewPlus Technologies/DAISY
Erik Bruchez, Orbeon
John Boyer, IBM (chair)
Joern Turner, DreamLabs
Leigh Klotz, Xerox (minutes)
Lars Opperman, Sun
Mark Seaborne, PicoForms
Nick van den Bleeken, Inventive Designers
Roger Perez, Satec
Uli Lisse, DreamLabs
John Boyer: We have a tentative keynote speaker but will have to wait a week or so for confirmation.
John Boyer: I've sent these out and we'll discuss them here.
John Boyer: Steven asks that we go
with one keyword per hashing algorithm for hmac and digest.
Erik Bruchez: I had a quick look. I'm
not sure why we would choose some other representation (lowercase
or without dashes), as those are the official names. So we should
have the name in the respective specs.
John Boyer: So for SHA it is "SHA-###"
and for MD5 it's just "MD5".
Erik Bruchez: If we do something else
we should have a reason.
John Boyer: Opinions for or
against?
Leigh Klotz: Sounds great.
Resolution 2007-08-1.1: We modify and accept http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=67 http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=67 to use the official names only (upper case and with hyphens where used).
Action 2007-08-1.1: John Boyer to fix http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=67 http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=67 to use the official names only (upper case and with hyphens where used).
John Boyer: Steven says, "Don't
start examples off with an error case." Highly editorial, I
imagine. Someone wrote in a comment on why the first example
returns zero. I thought someone explained a rationale.
Nick van den Bleeken: [IRC] it was me ;)
seconds("P1Y2M") returns 0 and not NaN because the input is a valid
duration but. the seconds function doesn't takes months and years
into account.
Kenneth Sklander: Any non-duration is
a NaN.
John Boyer: Steven didn't understand
why seconds("P1Y2M") returned a 0. The seconds function doesn't
take months and years into account. It sounds like he wants the
second example first; also it doesn't show an explanation of what
it returns. So it's just editorial.
Roger Perez: [IRC] Rafael sent an
email about this issue giving and additional sample:
seconds("P1Y2M3DT10H30M1.5S") returns 297001.5
Action 2007-08-1.2: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=70 John Boyer to swap example order and add explanation. Also do the same for the months function.
John Boyer: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=71
Steven wants choose to return objects rather than strings. http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=71
Erik Bruchez: I think that's not
directly this issue. The issue was that the specification for the
function specifies the type of the objects returned by saying it
depends on the two types of the input parameter; I found this
funny. I'm not sure I see the need; if you consider any xpath
function, the static return type is determined by the prototype of
the function. I think if you have to infer return types it's not
quite an XPath engine. I don't think we have that in XPath.
John Boyer: So it's really the second
sentence, if the two are not the same, you treat as if it were
comparison.
Erik Bruchez: I imagine if you pass an
int and a string, and compare them, it would convert the string to
an int. The function would then choose the second option. It seems
funny to make these requirements for hypothetical
optimizations.
John Boyer: Steven wants a second note
that says it returns objects, but you seem to want to strike the
second sentence and say it returns an object.
Kenneth Sklander: I think it's a bad
idea. It's not a hypothetical optimization; it's very real. I don't
see the problem with it; it's very clear.
Erik Bruchez: If I do choose(b, 1,
abc) then it will return NaN.
Kenneth Sklander: It will do the same
as XPath comparison. It will convert the integer to a string.
Erik Bruchez: OK choose(b, 1,
abc). I expect abc but in this case I
convert abc to integer.
Kenneth Sklander: That's incorrect. It
converts the number to a string.
Erik Bruchez: OK but if I choose to
return the first parameter, then I return integer.
Leigh Klotz: Returning only strings
isn't good for nodesets, so we need to keep choose.
Kenneth Sklander: Right.
Erik Bruchez: I'd like to look at
XPath 2.0. The if function is not a string function. So it's more
like the choose function we're trying to introduce. I'd like to see
what they do. They return either one value or the other, without
type conversion. To me, that makes perfect sense. I'm not sure
specifying the behavior brings anything useful, and the XPath 2 if
function doesn't do it.
Nick van den Bleeken: [IRC] http://www.w3.org/TR/xpath20/#doc-xpath-IfExpr
John Boyer: So the author can write
their own choose function to return a string or a number but if
they want to force the value to be a string they can wrap it with
string(). The optimization would run if the types are the
same.
Erik Bruchez: We would be preventing
different types from happening if we did it. This is contrary to
the XPath 2.0 if().
Nick van den Bleeken: [IRC] "Conditional
expressions have a special rule for propagating dynamic errors. If
the effective value of the test expression is true, the conditional
expression ignores (does not raise) any dynamic errors encountered
in the else-expression. In this case, since the else-expression can
have no observable effect, it need not be evaluated. Similarly, if
the effective value of the test expression is false, the
conditional expression ignores any dynamic errors
encountered"
Nick van den Bleeken: [IRC] do we need to specify
this for our choose function?
John Boyer: We can't do that in XPath
1.0.
Erik Bruchez: In the choose function,
we have to evaluate both parameters to get the type.
Nick van den Bleeken: You have to evaluate them
anyway in XPath 1.0.
Erik Bruchez: In Saxon, functions
receive expressions as arguments.
John Boyer: If you have choose(true,
a, b) then it's possible that only the second parameter would be
evaluated?
Kenneth Sklander: Not in XPath 1.0.
It's in section 3.2.
John Boyer: It XPath 2.0 we have an
issue with dependencies.
Kenneth Sklander: It's known. We'll
have to tackle that when we switch to XPath 2.0.
Erik Bruchez: In 3.2 of XPath 1.0...it
seems to be the case...I think you're right. What if the function
doesn't need the parameter? Would it be acceptable for an XPath 1.0
engine not to evaluate, if there are no side-effects.
Nick van den Bleeken: Dynamic exceptions won't be
thrown.
Erik Bruchez: In XPath 2.0 it would be
perfectly acceptable. OK so back to the types.
John Boyer: We have three parameters.
Kenneth, can you give us an idea of what happens if we drop the
type rationalization? If the author makes them the same, can you
still do the optimization?
Kenneth Sklander: Not exactly the
same, but there is no argument for not rationalizing them. I
haven't heard any argument for a use case that rationalizes them.
They have to be rationalized for use.
Erik Bruchez: If I don't know anything
about the choose function, I might be surprised if it didn't
convert arguments in a way I didn't expect. But the counterargument
is that that happens in XPath. The second argument is that in XPath
2.0 the if function is a mix of of choose and if.
Leigh Klotz: Are there places where it
converts to lose information?
Kenneth Sklander: It's going to be
converted where used.
John Boyer: The id function takes an
object. It can provide it different ways. You can get either a
nodeset or a string. The premature rationalization in choose might
interfere with it.
Kenneth Sklander: You can return a
nodeset with one or more nodes. Anyway, I have no strong feelings
one way or another. I do like it the way it is.
Erik Bruchez: How does rationalization
work if you have a nodeset vs a node?
Kenneth Sklander: As far as I know
XPath 1.0 doesn't have a node. Only nodesets.
Erik Bruchez: If you compare a node to
a nodeset what does that do?
Kenneth Sklander: If any node in one
nodeset is in another nodeset then it return true.
Erik Bruchez: So there are nodesets on
both sides.
Kenneth Sklander: We have four types
in XPath 1.0, nodeset, boolean, string, and integer.
Erik Bruchez: So a nodeset would be
perfectly fine.
Leigh Klotz: What XPath 1.0 functions
are polymorphic?
John Boyer: The id function.
Kenneth Sklander: So can always
analyze id inputs to find out. It's only extension functions. You
only need one to analyze the id function. If we introduce
choose...
John Boyer: With static typing you can
analyze choose at compile time.
Kenneth Sklander: I cannot think of
any example where you cannot do the analysis statically right
now.
John Boyer: I see that right now there
is no function in XPath 1.0 you cannot statically analyze.
Kenneth Sklander: In XPath 2.0 it's a
new game.
Erik Bruchez: In XPath 2.0 we already
have an if function that doesn't work the way XForms does. We're
now adding a new choose function, but if we have a conversion of
types useful for certain types of optimizations, you have to have
some types converted at runtime that wouldn't in XPath 2.0. So it's
yet a different selection mechanism.
Kenneth Sklander: It's not just for
optimization; for example, authoring tools with completion, at
design time. You would have to run the form to find that you have
an error. So it's not just a runtime optimization. John is right
that we can convert implicitly and optimize sometimes at runtime
but it's not just runtime. So let's leverage XPath 1.0 while we use
it.
Erik Bruchez: If you determine by
static analysis (string, int) then you can go further and detect it
statically at design time. If the user uses the string function
around the parameters, then it's easier.
Kenneth Sklander: I think it's better
to have static typing, but I have no really strong feeling about
choose. Maybe we should just decide something.
John Boyer: Sounds like it's a
no-brainer to accept Steven's issue here, but we have 4 who say
it's not a good idea, one saying it's a very good idea. It doesn't
sound like a strong consensus to change the spec, though we haven't
gotten to that issue here. It sounds like I don't need to do both
changes at the same time, right now, so I'll take the action item
to resolve 71.
Action 2007-08-1.3: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=71 John Boyer to add a note saying this is the object version of if.
John Boyer: A fairly strong case
would be made that this would be the first thing we've added to
XPath 1.0 that cannot be statically analyzed. It's not as XPath 2.0
compliant; it's still something that XPath 2.0 can do, and it's
consistent with XPath 2.0.
Leigh Klotz: XPath 2.0 has the
complete if function anyway.
John Boyer: So we'll have to deprecate
our own anyway.