Leigh Klotz, Xerox
Nick van den Bleeken, Inventive Designers
Steven Pemberton, CWI/W3C
Kurt Cagle, XMLToday
John Boyer, IBM
Uli Lissé, DreamLabs
Alain Couthuries, AgenceXML
Erik Bruchez, Orbeon [arrived late]
Kurt Cagle: Dan and I attended. I'm finding it interesting that 28msec is working on a way to usr FLWR-type expressions with JSON data structures.
*FtF minutes http://www.w3.org/MarkUp/Forms/wiki/Minutes http://lists.w3.org/Archives/Public/public-forms/2011Aug/0038.html http://lists.w3.org/Archives/Public/public-forms/2011Aug/0030.html http://lists.w3.org/Archives/Public/public-forms/2011Aug/0022.htmlSteven Pemberton: We edited the main spec and the modules.
John Boyer: I finished
switch/@caseref and repeat/@indexref, and it's in the wiki.
John Boyer: Steven, could you check to
see your use cases for indexref are satisfied? It was quite a bit
of editorial work because of the order of definitions in the
document, so I had to re-order and restructure the document. I
moved the definitions to the top of the section for easy reference.
I did this in the base document as well so it won't show as a
diff.
Steven Pemberton: Does the index
function work as well?
John Boyer: Yes. The index function
works and @indexref synchronizes it with the data.
Kurt Cagle: What is the regex
language for pattern? POSIX?
Leigh Klotz: http://www.regular-expressions.info/xml.html
John Boyer: ICU has more character
classes and nesting. Some differences are in the PXPath 2
spec.
Leigh Klotz: Is there a difference
between the regex in XPath 2 and XML Schema?
Steven Pemberton: There's a page on
regular-expressions.info for both.
John Boyer: There's a couple of modes.
Caret and dollar are different and there are powerful mode flags
(case-insensitive, multi-line).
Steven Pemberton: Ignoring
whitespace.
Kurt Cagle: What happened?
Leigh Klotz: We adopted label/@for and
made some choices. It's in the wiki [http://www.w3.org/MarkUp/Forms/wiki/Label_For_Attribute
]. We separated the two other issues from your proposal and put
them on the agenda for later discussion. (label/@xml:lang,
label/@model) and in the wiki [http://www.w3.org/MarkUp/Forms/wiki/Metadata_Controls].
Leigh Klotz: Has there been any
progress on either making the download work or changing the
introduction to say it is still in development?
John Boyer: Not yet.
Steven Pemberton: This is done.
Leigh Klotz: I see that XForms
interoperates well with HTML5 as it does with HTML4 via DOM and DOM
Events, both in the spec level and in browser implementations. For
example, the event for anchor change in URI should just work with
XForms.
John Boyer: Also working with XHTML as
XML and various MIME types should help.
Steven Pemberton: I don't believe
that's every been a real blocking issue. It didn't affect the
parse.
John Boyer: No, it's a huge problem.
If you tell the browser that it's HTML, some browsers will treat it
as case insensitive, mishandle close tags and instance tags,
especially as instance data.
Steven Pemberton: So you think that
will get better?
John Boyer: Yes, serving it up as
application/xhtml+xml will fix problems for browser that support
it, but some browsers simply displayed XML markup.
Leigh Klotz: So mime types and XML
work better. I'm happy to answer this.
Steven Pemberton: They say there are
no implementations of XForms, but there are many both in the
browser and out.
John Boyer: We have XSLTForms and
Ubiquity XForms. Mark Birbeck has a "Ubiquity" which contains an
XForms component and we're working with to get the content merged.
So we have a Dojo/YUI/JQuery like approach, i.e., non-native but in
the browsers.
Leigh Klotz: I had fun booting Linux
in my browser everytime someone called something in JavaScript a
non-native implementation.
ACTION-1823 Leigh Klotz to respond to http://lists.w3.org/Archives/Public/www-forms/2011May/0013.html and follow ons.
Erik Bruchez: I had a couple of
issues for review. The function has some history in EXForms and
Orbeon, and perhaps others that I'm not aware of. We had some F2F
discussions. I've written three versions of the same function,
which is a way to indicate two optional parameters. For now, I've
had valid() evaluate the entire subtree, but I'm not convinced. We
wanted to emulate submission's behavior. By default, we'd look at
the subtree and prune non-relevant nodes like submission does. I've
described this by a marking or selection algorithm, but said it
would "act as if" to allow other implementations. The function can
take a number of node. Besides that the function is very simple. It
retrieves the valid property, and relevance comes from the
recalculate event. After pruning nodes, if you end up with nothing,
the function returns false instead of true. Submission wouldn't go
forward.
Leigh Klotz: I've not seen that, for
example with submission GET.
Erik Bruchez: That might be true for
GET. But it does seem more reasonable to say the function should
return false for an empty tree, but I guess that's to be discussed.
One example would be a single node with no children and no
attributes, what would it say? I don't know if we can justify one
way or another.
Steven Pemberton: So it's valid if
empty?
Erik Bruchez: Let's consider a subtree
of nodes and one descendent node is non-relevant, it's easy. But
what if you have all non-relevant nodes, and an empty set of
nodes?
Steven Pemberton: Is that valid?
Erik Bruchez: I'm calling it invalid.
If you don't pass any nodes to the function, what should happen, or
an empty sequence. Is that valid? Then there is pointing to a
sequence of nodes, all of which are not relevant. I'm thinking that
you wouldn't on purpose point to a non-relevant subtree.
Leigh Klotz: What about two functions,
valid and invalid, as we have with with events and CSS classes, to
deal with the excluded middle, and to let the form author more
clearly describe intent.
Steven Pemberton: Or check use cases
first. I'd think it's valid unless proven otherwise.
Nick van: That's my belief too.
Erik Bruchez: It's like pruning that
happens during submission; if you have an empty set of nodes, it's
a corner case. I feel we could go either way.
Nick van: Do you have a use case for
everything being valid? You could specify a path. If one or both is
non-relevant it will not submit the non-relevant elements, but the
function will return false and the "and"...
Erik Bruchez: If you have an HTTP POST
the submission has no element and it stops.
Nick van: More clearly, if you have a
CC, amount, paymentType=cash|credit. Then you have an XPath
valid(paymentType), valid(CC), valid(amount), the CC will be valid
only paymentType="credit" and so the form will submit but your
valid(paymentType) will be false because it contains only a
non-relevant node.
Erik Bruchez: The right default might
be true then.
Steven Pemberton: That's my gut
feeling as well.
Erik Bruchez: For example, EXForms
relevance(), readonly() and required() functions would return
false, which is a little different. If you actually pass an empty
sequence of nodes, should it also return true? Is that valid as
well?
Steven Pemberton: I would honestly
suspect that it would, because I visualize using this function in
wizard-like applications and you can only go to the next thing when
the current thing is valid and filled in. If you get to a step
where you don't need to fill anything in, I wouldn't want to be
blocked there because it was invalid.
John Boyer: You could see people
constructing valid(a) and valid(b) and valid(c) instead of
valid(a|b|c).
Erik Bruchez: I think the case has
been made and I'm changing it.
Steven Pemberton: So resolved.
Resolution 2011-09-7.1: valid() of empty nodeset or empty sequence is true.
Steven Pemberton: "If the function
is used in model-binding expressions or compute expressions ...
terminate" means "you may not."
Leigh Klotz: <bind ref="a"
constraint="not(valid(.))" />
Erik Bruchez: We define recalculate
and refresh and so on at specific times and the refresh is supposed
to reflect the model data perfectly and be consistent (though
perhaps there are some funny cases). In that time before refresh
it's safe to use the function as you won't get an out-of-date
property as no external condition can influence the validity of the
data. On control bindings they'll be evaluated before refresh. In
response to UI events, assuming you haven't mutated the data you
are safe. On the other hand, you likely get out of date validity
data in bind/@ref and bind/@mips. There are situations where you
can use it and get correct results, but you'd have to be very
careful.
Steven Pemberton: I remember long
discussions with Roland Merrick and we never solved all the issues.
I understand the reasoning behind not wanting to use this in
certain cases. I can see someone wanting to say if valid(x)
then x+1 else 0...
Erik Bruchez: At the F2F I showed an
example where we used the valid function on MIPs. If you know when
it is to be evaluated, then it's possible. I could go either way:
we could just say be aware in MIPs. Unless as John says if the
dependency algorithm is updated there's going to be problems.
John Boyer: We would have say if
valid() appears in a calculate, the validity of the referenced node
(not their values) that has to figure into the dependency
algorithm. We'd have to define those MIPs as if they were
additional values for dependency tracking. It's more spec work and
more implementation work. So that's problem #1: it bleeds into the
dependency system. Problem #2 is that not all aspects of validity
can be assessed during recalculate when the function is called; the
design work to consolidate recalculate/revalidate hasn't been done.
We can address simple use cases without re-engineering model
processing by making the function available in some of the
places.
Nick van: I'd be happy to have the
functions defined by Erik in 2.0 and solve the bigger problem in
3.0.
Leigh Klotz: How about saying the
function is unavailable instead throws an exception? That lets
implementors decide.
John Boyer: We could say it's
unavailable and may throw an exception.
Nick van: Or just MAY throw and
exception.
Leigh Klotz: We could say it's
undefined and SHOULD throw an exception. Then if you implement it
you don't have to throw the exception.
John Boyer: We should document the
dependency order issue (avoiding stale results) and the separated
revalidate/recalculate. If your validity issue comes from
constraint and required, that comes from the ... We have two
problems: dependency ordering, and making the results
available.
Erik Bruchez: <bind ref="a"
constraint="..."/> <bind ref="b"
constraint="valid(../a)"/>
Erik Bruchez: In our implementation we
process binds in order and don't use the recalculation sequence
algorithm. If you reverse the two binds or if you have an algorithm
that doens't handle this order, you don't get expected
results.
John Boyer: You could have c = b + 10
and c depends on b.
Erik Bruchez: ...calculates
first...
John Boyer: The calculated value is
true if valid(*), then you no longer count on all calculates first
because constraints have to run first.
Erik Bruchez: I agree, it's a hard
problem to solve. But even without an algorithm that determines
order, it's still possible to do poweful things simply.
Erik Bruchez: #1 So we SHOULD
dispatch the exception but not say MUST? And #2 explain why?
Leigh Klotz: If we says SHOULD would
you have your implementation not dispatch the error?
Erik Bruchez: Probably.
Leigh Klotz: So Nick wants it in
XForms 3, you have a version of it, and we're putting spec-readers
on warning that if they want to have interoperability that they
can't implement or use it in model expressions.
John Boyer: and you could have the
constraint on a be "../c < 10" and you could have <bind
nodeset="c" calculate="../d+../e" And you can also have
calculate="... valid(...)..." so that you can't guarantee tha tall
calculates run before all other MIPs are reevluated
Steven Pemberton: A bit of
déjà vu for our discussions with Roland, but
I'm glad to see progress.
John Boyer: Change "control" to "form
control".
Erik Bruchez: OK.