Charlie Wiecha, IBM
John Boyer, IBM (chair)
Leigh Klotz, Xerox (minutes)
Nick van den Bleeken, Inventive Designers
Paul Butcher, WebBackplane
Roger Pérez, SATEC
http://lists.w3.org/Archives/Public/public-forms/2008Dec/0019.html
John Boyer: Our next call is
January 7, 2009. Should it be 90 minutes?
Charlie Wiecha: I think so. We have a
lot of modules.
Charlie Wiecha: We're planning
examples to develop for next year. Possibly an on-line, distributed
application game with rich presentation and data, and diversity of
client types (mobile, desktop). More a social distributed app (open
social?) than a game.
John Boyer: Two people might be able
to play each other.
Charlie Wiecha: Yes. That's better
than a paper. The Ubiquity story applied beyond forms. Gregory made
an analogy to the SVG-interest group, which is parallel to the
spec-writing group and collects best practices. We thought we might
spend time collecting jump-start info for an interest group.
John Boyer: And for a server?
Charlie Wiecha: We're still thinking
of what the work product is. Right now it's just "what should we
do?" showing cut-and-paste patterns.
Leigh Klotz: If you do it right there
won't be any hosting; you could get the free stuff elsewhere and
the rest will be small.
Charlie Wiecha: Yes, if it needs
hosting other than the pages that's an issue.
Leigh Klotz: I thought we fixed
this years ago.
John Boyer: That was if the url string
already had a question mark, we append a separator. But if you
don't have any URL parameters to add because serialization=none,
that didn't get accounted for. Is that problematic? We shouldn't
add it. Is that OK?
Leigh Klotz: It seems like an
editorial error.
John Boyer: Yes, it seemed like an
oversight. Does it seem like it breaks anything?
Leigh Klotz: No.
John Boyer: Leaving it in breaks
stuff.
Action 2008-12-17.1: John Boyer to fix section 11.9.1 to resolve http://lists.w3.org/Archives/Public/public-forms/2008Dec/0021.html to indicate we won't have the trailing ? or separator in the serialization=none case.
John Boyer: There's increasing
interest in the way XForms manipulates data within a document vs.
the need for archival records. A lot of the XForms actions (not
all) are reflected in the underlying data, which is different from
scripting, where you can add runtime data structures. In the past,
this capability of JavaScript to create anything at anytime that's
not in the document serialization has caused people to create
archival versions of document formats in which the JavaScript has
been turned off. In XForms, repeat and relevant are responsive to
changes in the data. So we can preserve dynamism while still being
archival because all the dynamism is reflected in the underlying
data.
Leigh Klotz: You need a super-readonly
though.
John Boyer: For purely archival
purposes, all they're interested in is the that thing that gets
stuck in the archive is a faithful rendition.
Leigh Klotz: I could see a "DOD
record" MIP type as one of the use cases for extensible MIPs. So if
you have a MIP that is a "DOD Record" attached to the data
instances (and not the state) then you can inject them, and not
worry about multiple MIP conflict. Archival data itself (POST and
PUT) would remain immutable via servers-side configuration but this
MIP extension would allow a record-aware processor to display the
record data.
John Boyer: Yes. We currently just
inject readonly at toplevel.
Leigh Klotz: You could style it and
tell it's different, and not have to worry about conflict with
readonly.
John Boyer: Perhaps we should solve
the multiple-MIP issue.
Leigh Klotz: I wrote that up a long
time ago; it's in the archives.
John Boyer: So back to the archival
format issue, the only way we don't have perfection where the state
is in the data is places such as setindex and toggle, managed by
the UI but not reflected in the underlying data. The difficulty is
that we haven't gone after this space before as a group, for
documents that serve as archival records. Any thoughts on how we
might proceed in that direction? Do you know of any other
standardization body that might address this?
Leigh Klotz: Are you asking if we've
looked at OASYS?
John Boyer: We don't talk much about
ODF and XForms in the WG, now that you mention it. XForms models
have been applied to ODF. Is there any interest in talking more
about ODF?
Charlie Wiecha: That's a broader topic
than archival. I'm confused about where the archival use case is
coming from; ODF is another document format.
John Boyer: I've been seeing this
issue with my customers; PDF for example is used in transaction
systems because it's blessed as an archival format. We haven't done
that with XForms.
Charlie Wiecha: The archival bit
confuses me. XForms as content management (see the public list) has
examples. http://lists.w3.org/Archives/Public/www-forms/2008Dec/0010.html
John Boyer: It would be preserving the
XHTML that presented the UI as part of the archival record. They
tend to pick PDF-based documents because they store the data and
capture the screen.
Charlie Wiecha: We were talking about
the backplane discussion yesterday; it's an integration exercise.
It's hard to get the right people together.
Leigh Klotz: John, you're in a
position to do a gap analysis. If it's just a few pieces of state
such as setindex, and a few rules for preferring internal content,
that may be easy. But if it's a multi-headed monster as Charlie
says, we can't get involved.
Charlie Wiecha: John you should be
able to do that fairly easily.
Leigh Klotz: Quite frequently, in the
past, "dump memory" has been the answer, viz. Microsoft Word and
Simonyi's memory structures.
John Boyer: ...
Charlie Wiecha: So the AJAX equivalent
is to serialize the entire running state. That's messy.
Leigh Klotz: I can see Prototype.js
doing that, serializing their state as JSON.
John Boyer: In the pure XForms case,
the state is pretty clean modulo a few issues. The surrounding host
language is the main issue.
Leigh Klotz: I'm all for you writing
these down: setindex state, a MIP priority structure (which might
be useful to us more generally), content inclusion. You can note
the XHTML issues but they're out of our control.
John Boyer: Now that the
implementation report is available, is it possible?
Leigh Klotz: Do we know which exact
version has passed? The test report is not 100% against the test
suite.
John Boyer:
http://www.w3.org/MarkUp/Forms/2008/XFormsBasicImplReport/BasicImplementationReport.html
John Boyer:
http://www.w3.org/MarkUp/Forms/Test/XForms1.0/Edition2/front_html/XF102edTestSuite.html
Leigh Klotz: There are many that
have "testcase is wrong" for example.
John Boyer: The test case was missing
a label; once they fixed that case it passed. But there are a few
others which they said it failed because they don't support it. But
the master document was an XForms 1.0 profile, and many other
implementations pass the tests.
Leigh Klotz: One could argue that the
failed tests are a symptom of removing XML Schema, even though we
know it's not true.
John Boyer: You can check each
specific case and see it's not true.
Leigh Klotz: I'd like to discuss
this with the group more fully. Is it OK to publish as XForms 1.0
R2?
John Boyer: In the XForms 1.1 case,
there is no XForms 1.0 Basic. It's just a conformance section. We
could have been more generous in the conformance section in XForms
1.1. But given that XForms 1.1 contains XForms Basic, do we
actually want to proceed with this document. How do you feel?
Leigh Klotz: I could see asking Steve
Bratt to approve this at the same time as we take XForms 1.1 to the
next level, since we can say that both XForms 1.0 and 1.1 both have
support without XML Schema.
John Boyer: OK.
John Boyer: On XForms 1.1, we need
more implementations.
Leigh Klotz: Maybe you can ask Joern
van Rotterdam from the public-forms list to test.
John Boyer: We need two for each
feature. They don't pass the test for the power() function. It's
useful for doing financial calculations.
Leigh Klotz: It's probably a Mozilla
structural issue for the need for a different super-reviewer for
math functions.
John Boyer: Anyway we'll need two
working implementations for the power function, among other things.
Some of the tests are feature-level and test many actual different
things. We have over 400 tests but they test 2000 things.
Action 2008-12-17.2: John Boyer to congratulate Joern van Rotterdam http://lists.w3.org/Archives/Public/www-forms/2008Dec/0010.html and ask for implementation report.
Paul Butcher: This is done. http://lists.w3.org/Archives/Public/www-forms/2008Dec/0012.html
John Boyer: Leigh?
Leigh Klotz: I haven't done it
yet.
Leigh Klotz: Charlie are you
planning to add the JavaScript binding?
Charlie Wiecha: Yes.
Leigh Klotz: I wonder if the getAsJSON
method could be only there, and not at all in the IDL. If the
module is implemented in JavaScript, then it will simply fall out
of the implementation anyway and the name is all we'd be
specifying. A note about the error behavior (what to do if there is
data loss in an XML to JSON conversion) is all we would need to
resolve.
Charlie Wiecha: I'll take a look at
that.
John Boyer: We got publication
approval for this document and it should be out tomorrow.
John Boyer: I found that we already
had repeat attributes repeating their content, so it turned out the
only error was in the example.
John Boyer: The other change was relevant to Leigh's question about JSON. In data submission http://www.w3.org/MarkUp/Forms/specs/XForms1.2/XFormsForHTML/index-all.html#data-submission I added an extra paragraph (4th, section 6):
The element or tag that configures the submission shall be augmented with a method named processResult()
John Boyer: So if you make any
changes you might look at this.
Charlie Wiecha: I'll take a
look.
John Boyer: I didn't spell out the
arguments. I did understand that in the case of JSON submissions,
the parameter is clear. We need to talk about what to do with XML
submissions here. But as a first draft we ought to have the
name.
Charlie Wiecha: Is there interaction
with the data instance module? It's JavaScript but it's more in the
submission module.
John Boyer: Right.
Leigh Klotz: Same theme, but a
different module.
Leigh Klotz: I don't understand
"element or tag".
John Boyer: We've used that language
elsewhere, so if it's wrong we'll correct it everywhere.
Leigh Klotz: And processResult is
just a JavaScript way of doing xforms-submit-done?
John Boyer: No, it's for a different
event that we haven't defined yet.
Leigh Klotz: What is the name?
John Boyer: You specify which
element's processResult to call. When that script gets written into
the page, that does it.
Leigh Klotz: I thought that you got
the JSON data itself and processResult was a way of getting it in.
prototype.js doesn't do this I think.
John Boyer: The server-side service
generates a response which has the JSON object as the answer to the
service surrounded by parentheses with your function name as the
handler.
Leigh Klotz: I'm seeing a different
split, but maybe I am looking at it with rose-colored
glasses.
John Boyer: I thought this is what you
had to do to make a JSON service work.
John Boyer: I noticed there were places where we didn't have function name consistency. getRuntimeElementById, processResult, getElementById, and then getvalue, setvalue, and so forth. For consistency it seemed better to make them all camel-cased. The markup is one thing, but the functions are another.
John Boyer: We have clearance of
FPWD, which means it's clearance to be on the recommendation track,
which is a good piece of progress for the working group.
Charlie Wiecha: There's also a new
co-chair of HTML.
Leigh Klotz: http://intertwingly.net/blog/2008/12/15/Co-Chair-HTML-WG
John Boyer: Yes, the HTML WG charter does obligate them to make some comments.
Nick van: I'm working on them, but
not for the next two weeks.
John Boyer: ..
Nick van: It's a bit of a hack.
John Boyer: It's unique to bind. No
other place attaches MIPs to nodes. We identify the node that it
attaches the MIPs to. It's the initial context provided by context,
not final. Every other element only talks about the in-scope
evaluation context; they don't attach anything to it.
Nick van: But what if we need a second
attribute like this and it won't be treated specially?
John Boyer: It's not special; it's
setting the context. bind has separate behavior,
attaching MIPs to nodes.
Nick van: You have to refer to the
context by name in the bind module.
Leigh Klotz: Why?
John Boyer: There are two; the initial
context has to be a defined concept because you have to have to say
what the context is before.
Leigh Klotz: But that's not in
bind.
John Boyer: The bind module will
inherit it. In the binding attributes module it defines it.
Nick van: I don't need to make the
definition in the bind module, only in the binding attributes
module (not my module). That's fine then.
John Boyer: The term for where the MIP
gets attached (with no nodeset) is the initial in-scope evaluation
context.
Leigh Klotz: Does that make binds nest
still? <bind nodeset="foo"><bind
readonly="true()"/></bind>
John Boyer: Yes.
John Boyer: <bind
nodeset="c"><bind context=".."
calculate="a+b"/></bind>
John Boyer: That now works. It
attaches to c but the context is the parent of c. The context is
evaluated before the nodeset attribute.
Leigh Klotz: So what does this do?
<bind nodeset="c" context=".." calculate="a+b"
/>
John Boyer: That sets the context
first.
Leigh Klotz: So that's the same as
this? <bind nodeset="../c" calculate="a+b"
/>
Nick van: If there are more siblings
of c, it will go to the parent of the element.
John Boyer: We're talking about how
bind works. So if I type this:
John Boyer: This might be an inner
bind, but all the context does is to accept the in-scope evaluation
context. The nodeset produced by the bind produces a set of nodes
and that set of nodes is used to evaluate calculate. So when a
nodeset attribute exists, it's taking control. <bind
context=".." nodeset="c"><bind
calculate="../a+../b"/></bind>
Nick van: <bind nodeset="c"
context="../a" calculate="b + c"/> isn't the same as
<bind nodeset="../a/c" calculate="b + c"/> if
you have multiple a elements (I think)
John Boyer: The context attribute
doesn't have any effect on evaluating the MIP expressions. The MIP
expressions are evaluated relative to the nodeset. The context
attribute expresses the first node rule, and that's consumed by the
nodeset. It provides the subsequent evaluation context.
Nick van: In my example,
context="../a" gives you the first a element. Then you evaluate c
and you get all the c children. In the first example,
you get all the c children of all a
elements.
John Boyer: That's right.
Leigh Klotz: Leigh was asking if
prepending context to nodeset was the same and it's not because the
result of the expression retains only one node.
John Boyer: So there are two answers.
It's not the same. And it's not the same because the calculate is
relative to the nodeset. If the bind doesn't have a nodeset
expressed, the calculate is relative to the in-scope evaluation
context, which the context attribute affects.
Leigh Klotz: So look at context, then
nodeset, then that's the new context, and calculate is evaluated
with regard to that.
John Boyer: And then the answer of
calculate goes back to the nodeset, one or more nodes. If there is
no expressed nodeset, then we attach it to the last-expressed
parent bind element. We don't attach MIPs to in-scope evaluation
context nodes; we attach them to nodes specified by nodesets in
binds.
John Boyer: This leads us back to the
.. case. So you don't have to type
../a+../b. <bind nodeset="c"><bind
context=".." calculate="a+b"/></bind> So the inner
node sets the evaluation context and the outer nodeset sets the
result.
Leigh Klotz: So in XForms 1.1 we
have to use two binds, but in XForms for HTML, we say it's done as
if it's done this way.
John Boyer: Right. So it is equal to
<bind nodeset="c"
calculate="../a+../b"/></bind>
Leigh Klotz: Do we have examples of
this idiom in 1.1?
John Boyer: The context attribute on
bind is a 1.2 feature.
Leigh Klotz: Ah, that's what was
confusing me.
Nick van: <bind
nodeset="c"><bind context="../line"
calculate="sum(a)*b"/></bind> isn't the same as
<bind nodeset="c"><bind
calculate="sum(../line/a)*../line/b"/>
Nick van: We probably need to put a
note in the spec saying to be careful.
John Boyer: Each inner bind receives a
single node from the outer bind. A limitation of the context
attribute is that you lose the position and size.
Nick van: In the first example I
posted, you will get the sum of all a elements of the
first line. In the second you'll get all lines.
John Boyer: Can you put it in email?
It looks like an author issue.
Leigh Klotz: I think it's a tricky
author issue.
Nick van: It's not just a common
prefix elimination. You can't do it in all cases. If there are two
nodes at the common point then it's not the same.
Leigh Klotz: So the result of Nick's
calculation changes because when he moves the common prefix to the
context, so the simple explanation that context can be used to
reduce common prefixes is simplistic.
John Boyer: So you have to write a
more complex expression.
Leigh Klotz: I'm worried about changes
to existing expressions that work.
John Boyer: Which you can't because
there is no context attribute in 1.1 anyway.
John Boyer: But first-node-rule,
interesting point.