Alain Couthures, AgenceXML
Nick van den Bleeken, Inventive Designers
Steven Pemberton, CWI (chair)
Leigh Klotz, Xerox (minutes)
Uli Lissé, DreamLabs
Erik Bruchez, Inventive Designers/Orbeon
Erik Bruchez: It's a bug-fix and maintenance release.
Steven Pemberton: They attended XML Prague and announced it there.
Steven Pemberton: Many people came
up to me after and said they would research XForms.
Nick van: An interesting
conference.
Steven Pemberton: It was themed around
bringing HTML and XML closer. Anne von Kesteren was there. He gave
a talk on what he calls "XML5," adding error correction to XML
parsing. A community group started up to look into error recovering
parsing for XML. It was said that in the pipeline you don't want
error recovery, but possibly at the last stage in presentation you
do.
Steven Pemberton: There were
presentations on XPath 3.0. I saw several things in there that
would be very good for XForms: map/reduce, for example.
Leigh Klotz: So they have first class
functions?
Steven Pemberton: Yes. It's a much
more powerful language.
Nick van: Also partial
invocation.
Steven Pemberton: Useful for map and
reduce as well.
Leigh Klotz: It's in WD as of
December.
Steven Pemberton: Any
comments?
Alain Couthures: Varables in XSD 1.1
at XML Prague.
Leigh Klotz: Shoudln't we allow text
content and allow @value to be optional?
Steven Pemberton: To be
consistent.
Erik Bruchez: That's what we do. You
can do more in XSLT because you have sequence constructors, but
that becomes more complicated.
ACTION-1867 Nick Van Den Bleeken to Van den Bleeken to make var take constant child content.
Leigh Klotz: For uses like
concat($quote, x, $quote).
Steven Pemberton: It's more like a
constant than a variable.
Nick van: Right. For each
invocation.
Leigh Klotz: We don't have
types.
Nick van: The type information doesn't
flow in our system, becuase there were problems. Type aren't valid
during form filling.
Erik Bruchez: It's a little different
for variables than for instance types. If you run an XPath
expression in XSLT 2, I understand there are two aspects: it makes
sure the value is exposed as the specified-type with coercion as
necessary, and if not possible it throws an error. We've thought
about doing this in our implementation as well. You can have
select="elt" as="string" and I think that will work as
if you had used the string function. On the other hand if you have
as="date" and it's not a date you get a dynamic
error.
Leigh Klotz: I would see it useful
where you declare a variable as a boolean and later use it in
@if.
Erik Bruchez: Exactly. Types add
robustness. We do need to decide what to do to add improved error
handling; we need to decide what to do if the value doesn't match.
Is it an empty sequence?
Nick van: If you specify the type, you
could already do an if inside your selection to convert to an empty
sequence.
Leigh Klotz: In our pipeline language
we have name, type, and default. If the type coercion fails or you
get empty sequence you get the default value.
Steven Pemberton: Does anybody else
implement this?
Leigh Klotz: Like this?
<var name="a" type="integer" value="x" default="0" />
<var name="a" value="saxon:try(xsd:integer(x), xsd:integer("0"))" />
Erik Bruchez: Last week we talked
about picking default values. So if you have a variable and it
fails type checking, what do you do? Assign an empty
sequence?
Leigh Klotz: I proposed it in the
example.
Erik Bruchez: It seems heavy to have
to specify the default every time.
Leigh Klotz: I think it decreases
robustness not to have to specify it.
Erik Bruchez: It would be good to have
a mode somehow to turn on global defaulting.
Leigh Klotz: Yes, as long as it's
something you turn on.
Erik Bruchez: I would say it's the
same way as everything else; it dispatches the event and you can
catch it but if not it stops everything. You need to decide what
happens to the failing variable. If it is in a UI element, it
behaves like a control.
Leigh Klotz: Another thing we have is
an isVariableDefined? function. The XSLT folks don't see the need
but I think with dynamic code paths we do.
Erik Bruchez: Java for example doesn't
have it.
Steven Pemberton: XPath 3 has
introspection; you can ask about functions.
Erik Bruchez: If variables are
lexically scoped, then you can mark everything inside that scope as
non-relevant and so you don't need default values for errors. If
you want a default, you could introduce try/catch at the XPath
level.
Leigh Klotz: We've found try/catch not
to be appropriate for this condition; this is about crossing
boundaries and defining defautls for pageSize, sortOrder, etc. This
isn't about 24x7 running, it's a programming style.
Erik Bruchez: There's a risk that
someone might think it should do that with any type of error.
You're making a distinction between type checking and coercion. In
Saxon you could pass the type coercion down to the evaluation.
You're making a distinction between the two; how would you make
that distinction?
Leigh Klotz: Perhaps the name default
isn't right.
Erik Bruchez: It's fine to default,
but not for type checking. We have defaults for values. That's
hiding programmer errors too.
Leigh Klotz: We use it for query
string parsing, so it's not necessarily programming errors.
Erik Bruchez: Scala has
expression-or-value-if-null. A function might be a better solution.
We can consider adding one if we're not considering adding
one.
Leigh Klotz: That might work as well.
So where does it leave us on type?
Steven Pemberton: It doesn't do any
harm.
Erik Bruchez: It doesn't do any harm,
but we do need to decide if we need error handling or
errored-values.
Leigh Klotz: You mean empty sequence,
empty string, zero?
Erik Bruchez: It depends on whether we
have error handling. If we make changes to error handling, if you
cancel the event we need to decide what happens to the value. We
have three possibilities: @default (exception if none), or have
empty defaults (empty seuence, "", false, 0), or unusable variables
and anything depending on it marked not-relevant.
Erik Bruchez: The default-default
doesn't seem to be workable for enough cases.
Erik Bruchez: So we could add @type
and decide what to do about errors when we do error handling
later.
Steven Pemberton: Does @type depend on
that discussion?
Erik Bruchez: No. So do we want an @as
or @type attribute? I think we'd be interested in implementing
that.
Nick van: You probably want @as if you
want to do conversion. @type implies it already has the type.
Erik Bruchez: That's the choice they
made in XSLT. In Scala, you specify type but it
implies coercion. It's nice because it's short.
Leigh Klotz: We shortened variable to
var so we could shorten as to a.
Steven Pemberton: Could we make an
interim decision?
Leigh Klotz: I'm happy to say we want
types but we don't have a name or error handling yet.
ACTION-1868 Erik Bruchez to summarize problems with error handling and three options for variable type handling.
Steven Pemberton: I have two
questions. I can't find where we de-reference variables in the
spec.
Nick van: It's in the XPath
module.
Steven Pemberton: OK. Is the value of
the variable updated on refresh, as part of the dependency
graph?
Nick van: If it's in an action, it's
every time the action runs.
Steven Pemberton: You say it's allowed
everywhere but in the model.
Nick van: If it's in the UI, it's on
refresh.
Steven Pemberton: Then it can change
during its lifetime. Does it take part in the dependency algorithm
them?
Nick van: No becuase that's only in
the model and it can't be done in the model, or it's done in an
action and done then.
Steven Pemberton: Will users complain
they can't do them in the model? Constants, for example? Do we
forsee that as a problem?
Nick van: We'd need more research
about that. Can you use them in bind? We don't have any
implementation experience.
Leigh Klotz: We could add a note
asking for implementation experience for variables in the
model.
Nick van: I can add that.
ACTION-1869 Nick van den Bleeken to add note asking for implementation experience for variables in model.