Charlie Wiecha, IBM
Erik Bruchez, Orbeon
Kenneth Sklander, PicoForms
Leigh Klotz, Xerox (minutes)
Mark Birbeck, x-port.net
Paul Butcher, x-port.net
Roger Pérez, SATEC
Steven Pemberton, CWI/W3C (Chair)
Keith Wells, IBM
Uli Lissé, DreamLabs [late]
http://lists.w3.org/Archives/Public/public-forms/2008Aug/0082.html
Steven Pemberton: Our wiki is being
migrated to MediaWiki. It's OK that the old Wiki is not being
migrated, right? Nick and Leigh should check. Nick's not
here.
Leigh Klotz: If I don't know what's
there and it's member only then we don't need it.
Steven Pemberton: It seems to work
somewhat.
Charlie Wiecha: He seems to have a
different approach from Ubiquity. It doesn't seem to be a scripted
definition of each element, but a transcoding into JavaScript. It
would be nice to have more focus on Ubiquity but it's a different
approach.
Leigh Klotz: It's a separate effort
and having someone work on one thing doesn't keep people from
working on another.
Registration at http://www.w3.org/2002/09/wbs/35125/TPAC2008/
Steven Pemberton: Please register;
so far only four.
Charlie Wiecha: The hotel deadline has
been extended.
Steven Pemberton: I think they've
replied satisfactorily be referring to the XML language to decide
what are URIs. I think we should be happy with that comment..
Right? Silence is content.
Steven Pemberton: Our next comment was
that LEIRE were not XML compatible and they said they'd add a note.
OK.
Steven Pemberton: The next comment is
an explanation of where the change is being made, so that's
satisfactory.
Steven Pemberton: I think the last one
is based on a misunderstanding from our point of view. We asked why
it was a PER because it looked like implementations would have to
change. They replied that there is no normative change and only
pointed to a different reference for LEIRE rather than describing
it themselves. I personally think these replies are OK.
Steven Pemberton: Do we reply saying
we are happy?
Action 2008-09-10.1: Steven Pemberton to reply to http://lists.w3.org/Archives/Public/public-forms/2008Sep/0012 0013 0014 0015 saying we are satisfied.
Kenneth Sklander: My conclusion is
that we should move to XML Schema 1.1 at the same time as we move
to XPath 2.0. We should be careful about the PSVI and XPath
evaluation context, but those are just technical challenges.
Steven Pemberton: You don't think
there are any comments?
Kenneth Sklander: I have two comments
that I wrote in the mail. There is a mistake about digits and the
other is that they asked for feedback on assertions on simple
types. I think we should have them.
Steven Pemberton: The comment?
Kenneth Sklander: You can have
infinite digits in a floating point number; they meant significant
digits. If we allow assertions with simple times, as we have with
bind/@constraint, it is pretty good. The assertions in XML Schema
1.1 don't allow reference to other documents, so we still need our
bind.
Steven Pemberton: Do we have an
opinion that assertions cannot apply to parents or siblings?
Kenneth Sklander: I think they
can.
Steven Pemberton: On an element, the
XPath may not refer to a parent or sibling of an element.
Leigh Klotz: Maybe it's for applying
mapreduce to extremely large XML documents.
Kenneth Sklander: So if people want to
do it they can do it with constraint. I don't know why they have
it, I don't think we should complain about it.
Steven Pemberton: You can't say then
that input is a child at any level of form.
Kenneth Sklander: You can.
Steven Pemberton: You have to have two
content models.
Kenneth Sklander: They do it with
"wire cuts"?. I don't think it's a problem for use in XForms, but
maybe a problem for validating an XForms document.
Steven Pemberton: Anything in XForms
could be in an instance.
Kenneth Sklander: And you can then use
bind. So I think it's perfectly satisfactory.
Steven Pemberton: I have personally
been asked our opinion of this feature.
Kenneth Sklander: Within a forms
processor, there are other ways to do it.
Leigh Klotz: So we can say we're going
to keep our bind attribute because it's more functional.
Steven Pemberton: Yes.
Kenneth Sklander: And it can do
cross-document reference.
Steven Pemberton: Do we resolve this
XSD when it is a specification?
Kenneth Sklander: We can't chose to
before XPath 2.0. This will be in REC before we get 1.2 out. I
don't think we can resolve before 2.0. Within our model, there will
be two stages for XPath evaluation so there may be some things to
think through, especially if we allow access to XPath MIP
functions.
Steven Pemberton: Any other comments?
Mark? Paul? He sent his review a couple of hours ago.
Paul Butcher: I don't know.
Steven Pemberton: I might be missing
something.
Kenneth Sklander: He explicitly stated
in his mail that he has no formal comments.
Steven Pemberton: So we just have your
two comments.
Leigh Klotz: And the third comment
that we will continue to use bind/@constraint for two
reasons.
Steven Pemberton: Yes, not being able
to refer to siblings.
Leigh Klotz: And other documents.
Action 2008-09-10.2: Steven Pemberton to reply to XML Schema 1.1 call for comments with two comments from http://lists.w3.org/Archives/Public/public-forms/2008Sep/0016 0019 0020 and with a note that we will continue to use bind/@constraint for two reasons: reference to parents and siblings and reference to other documents.
Uli Lissé: [joins]
Steven Pemberton: Have we discussed
this.
Charlie Wiecha: Yes.
Leigh Klotz: Yes, we're going to break
this up into 2.1, 2.2, 2.3 and 2.4 as separate documents.
Steven Pemberton: This is a review
for structure and contents. It adds element bind and attribute
bind. Nick has a question about where we resolve id
references.
Paul Butcher: Should that be in the
host document, or possibly in repeat where it becomes different
from anything else? Possibly in switch though I'm not sure if
that's strictly true. You can have multiple instances of the same
id with repeated content, so you need a way of resolving it. So in
repeat, the current index, or a descendent of the ancestor
repeat.
Steven Pemberton: I wonder if we need
to define it in two places, the general case and special treatment
for repeat. Here we're talking about bind and bind is never the
child of repeat.
Leigh Klotz: I agree, I don't think
the id reference definition belongs here. And computed expression
as well.
Steven Pemberton: Let me ask the
implementors. Is there anything to be gained by using ID? What's
the value if id being a built-in datatype of XML? Has it made life
easier or harder? What if we'd defined something such as "name" or
"identifier" and used that.
Paul Butcher: To be honest, we don't
pay any attention to the type. We get it from the browser.
Leigh Klotz: So the browser is
depending on the type.
Paul Butcher: True, yes.
Steven Pemberton: Then you don't use
standard DOM access for IDs when you're using repeat?
Paul Butcher: That's true, for repeat.
We maintain our own list.
Steven Pemberton: So we do need our
own definition. I suppose we chose id because we intend XForms to
be embedded in other languages and we want id to be used
consistently across other documents.
Paul Butcher: As a loaded DOM, it
behaves like an ID, in the sense that you should have one. Only in
the live state does it become a different game. You can validate
the document against the Schema, but in a live XForms document the
treatment is different.
Steven Pemberton: So what answer do we
give? Is there a mini-id module? Do we put it in toplevel? It needs
to be involved with repeat? Is it two-stage, defined half somewhere
else? Maybe we don't have a sold feeling for how the whole thing
combines to be able to answer that yet. We'll have to ask whoever
edits this.
Erik Bruchez: Up to 1.0 2nd edition,
we did not explicitly mention "id":
http://www.w3.org/TR/2006/REC-xforms-20060314/slice3.html#structure-attrs-common
Steven Pemberton: We had a reason
for not doing it and we realized it was a mistake. We still had
things which referred to ids. We still had it and had to resolve
it.
Leigh Klotz: We had a conformance
requirement that the host language provide one.
Steven Pemberton: Are we otherwise
happy with this module?
Leigh Klotz: I note in a similar
vein, this module defines "computed expression" but doesn't use
it.
Steven Pemberton: I wonder why?
Leigh Klotz: Probably for MIPs but no
MIPs are defined here.
Steven Pemberton: So what do you
propose.
Leigh Klotz: So where do we put things
that are defined in one place and used in another.
Steven Pemberton: We should pass that
on to Nick.
Steven Pemberton: We have the same
comment here for id and repeat.
Steven Pemberton: Should we use XML
Events 2 or not? Otherwise, I think it's OK.
Charlie Wiecha: We said we'd still
need this function as we are not yet going to XML Events 2 in
1.2.
Leigh Klotz: I proposed this in
2003 or so and I'm glad to see it's acceptable.
Steven Pemberton: I don't remember why
it was said to be impossible before. Leigh?
Leigh Klotz: It was because the XPath
1.0 Rec does not indicate a way to do this. I pointed out that
every XPath engine I've seen lets you specify a return type, and
from there it turned into a discussion of COTS.
Steven Pemberton: Paul?
Paul Butcher: Changing it now will
break existing documents. In XPath, empty nodesets are false and
everything else is true. boolean-from-string is the other way
around, so that if true were the default return and false or 0 were
false, then the automatic casting would work. But that requires
changing the behavior of boolean-from-string, or having a special
boolean-from-string semantics for this default casting.
Kenneth Sklander: It's a little more
as it destroys the backward-compatibility of properties.
Paul Butcher: That's the kind of thing
I'm getting at with boolean-from-string. An empty nodeset would
remain false. Oh, I see, sorry.
Steven Pemberton: I do like the
idea of casting strings, because some of the hardest to debug
XForms have been where I thought I had a number and I didn't.
Trying to work out wrong types is really hard.
Paul Butcher: I'm not sure how this
would help. This is MIPs and not internal to XPath.
Steven Pemberton: I meant in MIPs,
using strings. Lexically they were numbers. So my MIPs weren't
working. Isn't that what you're suggesting here?
Paul Butcher: Here it's the string
value "false." If your MIP returns the string "false" that's
"true".
Steven Pemberton: You said it was a
good idea.
Leigh Klotz: Originally when I
proposed it, yes. Now I am willing to listen to arguments about
backward compatibility.
Kenneth Sklander: If you want to use
boolean-from-string, we have to redefine boolean-from-string. That
will mean that boolean true or false MIPs would still work.
Paul Butcher: Except for "false"
Kenneth Sklander: Everything else we
could retain by using a combination of boolean and
boolean-from-string. If the string "false" becomes false.
Leigh Klotz: You could say that's
breaking backwards compatibility but that is the case we're trying
to fix.
Paul Butcher: If we were to use
boolean-from-string as is, then any existence test would become
false and that would become false.
Leigh Klotz: Right, I meant with the
redefined boolean-from-string. If we start out trying to make
string "false" mean boolean false, we can't then claim it's
breaking backward compatibility.
Kenneth Sklander: We can just say that
MIPs treat string "false" as false. They already treat 0 as
false.
Leigh Klotz: That's more
straightforward.
Steven Pemberton: Paul, are you OK
with that?
Paul Butcher: Yes.
Leigh Klotz: Do we need to say
something about 0?
Kenneth Sklander: We already say that
because we refer to the XPath boolean function which treats the
number zero as false. There is also NaN which is treated there as
well so we don't need to say anything.
Steven Pemberton: Resolved?
Resolution 2008-09-10.1: For future versions, we change MIPs that accept boolean values to say that they use the XPath boolean function to convert the value to boolean, except if the value is the string "false" in which case we treat it as a boolean false.
Isn't it about time we add an xforms-control-initialize event?
Steven Pemberton: I'd say that we've struggled with use case 2 for a long time. I don't quite understand the proposed solution, though I recognize the use cases.
Paul Butcher: You could bind on the
ancestor node and hide on invalid.
Steven Pemberton: That would require
you to have control over the structure of the data.
Paul Butcher: Or that your form mirror
the structure of the data.
Leigh Klotz: In my email client
example, I also needed parallel structured data: checkboxes next to
each email item, which aren't part of the item original data. It
seems like a more general issue.
Steven Pemberton: I think we should
discuss this at the F2F as we promised the wizard issue would be in
a later version in XForms 1.0.