Charlie Wiecha, IBM
John Boyer, IBM (chair)
Kenneth Sklander, PicoForms
Leigh Klotz, Xerox (minutes)
Mark Birbeck, WebBackplane
Nick van den Bleeken, Inventive Designers
Paul Butcher, WebBackplane
Roger Pérez, SATEC
Uli Lissé, DreamLabs
Keith Wells, IBM
Erik Bruchez, Orbeon
John Boyer: Aside from TPAC, we only get Steven for one F2F per working group. I couldn't remember whether we managed to have co-location of XHTML2 and XForms.
Keith Wells: I am working on it. I'm having some trouble.
Kenneth Sklander: I sent it again.
I sent you the excel report and the XHTML implementation report by
Steven.
Leigh Klotz: Sorry for the trouble
again.
John Boyer: We talked about doing
this in XForms 2.0. In XPath 1.0 when you convert a string to a
boolean is true unless the string is empty. I'm trying to achieve
referring to a node whose content might be false and have the
result of that register as a false. XPath converts a nodeset to a
boolean if the nodeset is empty. In the example, with
<isManager>false<isManager> the MIP
relevant="isManager" would get true because there is a
non-empty nodeset, so we have the boolean-from-string
function. I think in September we resolved not to do the final
conversion for MIPs as if processed by boolean-from-string, but
instead to use some language from XPath 2 which says that a string
with the content of false "will be converted" to a boolean false.
But that doesn't work when I'm trying to do a nodeset, unless we
assume all our boolean MIPs are first converted to string, and we
don't assume that either.
Leigh Klotz: They're not single-node
bindings?
John Boyer: They can result in a
string, or a boolean. Right now we cast the results to a boolean,
which is the problem.
Nick van: For relevant we use the
availability of a node to switch the relevance. Is there an exists
in XPath 1 or is tht only XPath 2?
Erik Bruchez: [irc] only in XPath
2
John Boyer: You can say it with
count.
Paul Butcher: It could break forms
that already exist, which is what we tried to achieve with this
wording.
John Boyer: In the next message, Erik
says he's only 40% convinced. Or standardize on a document within a
spelling of "false" and test for that.
John Boyer: Part of the reason for
that, in my earlier email, suppose we for a moment we did assumed
that the final result of result of relevant MIP was processed by
boolean-from-string. What if instead of relevance I wanted to use
readonly. I'd be tempted to say the section is readonly if the
person is not a manager. That doesn't work because the cast of
ismanager is inside the expression so there's nothing we can do
about it. The user is forced to type
readonly="not(boolean-from-string(isManager))"
Erik Bruchez: I don't think we can
make XPath easier with external changes. Making a determination
that ... is going to be hard to fix.
John Boyer: I also found it convincing
in your email that in [the onramp] we're standardizing the
automatically-generated data model so we can use true
and false and tell them to compare to
true and false. So maybe we should
consider backing off this previous resolution. It is what it is for
XForms 1.1 and use boolean-from-string or direct comparison.
Nick van: With the not() example, or
the same XPath expression elsewhere, I can see how it would be
confusing.
Erik Bruchez: I think you made a good
point for the simplified version; someone not familar with XForms
would not have less trouble with strings than converted
booleans.
John Boyer: So the proposal is that we
resind the prior resolution and not do anything special for string
false in XForms 1.2. Is there any objection to that proposed
rescinded resolution.
Resolution 2008-11-19.1: We rescind http://lists.w3.org/Archives/Public/public-forms/2008Sep/att-0025/2008-09-10.html#resolution1 in the light of this discussion, http://lists.w3.org/Archives/Public/public-forms/2008Sep/att-0025/2008-09-10.html#resolution1 and http://lists.w3.org/Archives/Public/public-forms/2008Sep/att-0025/2008-09-10.html#resolution1
Action 2008-11-19.1: John Boyer to update onramp boolean MIP examples to use boolean string comparison.
John Boyer: I've renamed it XFormsA; there's been discussion about other names. Other names that have come up
Uli Lissé: XForms
Compact
Mark Birbeck: XForms
Uli Lissé: XForms lite
Kenneth Sklander: I like Mark's
suggestion.
Leigh Klotz: Which?
Mark Birbeck: "XForms." Do we expect a
set of features only in this specification and not in XForms full?
If we do, then I'm against that (we can have that discussion). If
things like @name are going to find their way into the new
language, it's not a new language but instead a new way of
explaining it. So I think of this document as the onramp, or
"XForms -- the good bits," like Cockford's approach to JavaScript.
"Here's the bits to focus on. So, there's lots of other stuff, but
look at this way for now." There are some genuine things that are
missing, such as name, and a few bits at the bottom of the stack,
but I'm not sure there's a new language or a new profile. I'm not
convinced there's a new language or profile, so not XForms Basic or
XForms Tiny. So a primer could be called XForms Compact; it's
ambiguous. You could argue it's the quick way in. So, the question
is: are we creating something new, or adding a few extra bits, in
which case we don't need a new language.
John Boyer: I have a couple of
responses. Regardless of the features, there is a possibility that
looking independently, it's conceivable that browser vendors might
pick up this document and implement it without implementing full
XForms; even if they did that, it might be useful. They might
implement the required parts. We don't know what that conformance
section will end up lookign like. It's fairly complete now, but we
don't know the future. Then, applying that the a JavaScript
implementation of XForms Full could use more of the platform. So it
is conceivable that user agent vendors could implement lower rungs.
At the other end, ODF only has a model but maybe one day they will
have XForms UI controls. Do we actually want calculate on input in
the XForms namespace? In the Ubiquity library we are attaching
attributes to elements in the XForms namespace, so I removed that
line from the spec that says you shouldn't do that. So if this is
part of XForms Proper, we'd have to have implementors implement
these.
Leigh Klotz: Kenneth, what do you
think? You had concerns about XForms Tiny.
Kenneth Sklander: I agree with the
name. It would clutter the world to have the same functionality
called something else. I can only see that causing trouble with
adoption.
Nick van: Normal XForms, but then a
lot of the other bits are targeted to HTML and you can express them
in the same way (@checked, @value). There are some other strange
things that come from HTML Forms, so I personally don't want them
added to "core XForms" but an optional module is no problem.
Mark Birbeck: That's an interesting
point; some of the attributes seem useful, but there may be one are
two that aren't appropriate. John, in terms of implementation, I
thought we already had that. We have modules such as XForms
Submission and XForms Message and there's not been an enormous
amount of progress on those, but someone could implement submission
at the API level and not at the markup level.
John Boyer: So what do we call this
module?
Mark Birbeck: ...
John Boyer: There's no way around
adding @checked and @value.
Mark Birbeck: I think we should add
them; we have bigger fish to fry. Charlie:[irc] for that last
module, I think Mark just said it well: XForms HTML module
Mark Birbeck: We wouldn't have started
with a clean slate years ago if AJAX had been popular. I have read
past minutes, about label being a child of input. HTML Forms are
everywhere and we want to bring those people along. What if we had
done that; we'd probably still have a checked attribute. So XForms
for HTML keeps it; it's not what like Steven's tutorial. It's a
bridge module.
John Boyer: Steven's not here; I want
to point out that Steven had a neat quote in 2008: "If all design
work were done by paving cowpaths, then nobody would ever build any
bridges."
Charlie Wiecha: kind of like just
XForms HTML, period i.e. "HTML" rather than "Tiny". It's punchier
than XForms for HTML. Like XForms Compact.
Leigh Klotz: But HTML isn't an
adjective.
John Boyer: Right. So it could be the
XForms HTML Module or the XForms for HTML Module.
Mark Birbeck: Or the XForms HTML Forms
Module.
Charlie Wiecha: Or XForms for
HTML.
Nick van: Then it looks like we're
putting Forms into HTML.
John Boyer: It hints at putting XForms
into non-XML documents. These attributes could be applied
elsewhere; the spec does imply that that could be done still. It
does explain @checked, @type=radio etc.
John Boyer: Do we need a compact, or
within this module do we need more conformance?
Charlie Wiecha: It think you need the
message that this doesn't...
Leigh Klotz: I think we need two
specs; the chatty version called XForms for HTML, and the spec
version which is the XForms Attribute Injection Model.
Charlie Wiecha: The HTML one would
have @type and and @checked.
John Boyer: I wouldn't want to create
a document for just @type and @checked.
Leigh Klotz: Why not?
John Boyer: We have to request a
shortname for each.
Leigh Klotz: Or a short number, as XML
Schema.
John Boyer: It's not that
important.
Leigh Klotz: Right, but if we decide
it is then we can do a separate spec.
John Boyer: ...
Leigh Klotz: So just drop the XForms
element version out of this document, and call it XForms for HTML,
and if we need to do a module for exact XHTML modularization then
do a separate spec.
John Boyer: The XForms for HTML
Module: Streamlined Expression of Data-Rich Web Applications
Charlie Wiecha: Dropped.
John Boyer: Proposed name: THe XForms
for HTML Module
Charlie Wiecha: XForms for HTML
John Boyer: Not a module?
Charlie Wiecha: A module, but we don't
say so.
John Boyer: What about the XForms
Instance Module
Charlie Wiecha: That's a techier thing
for techier audiences.
John Boyer: Straw poll in IRC?
John Boyer: All right. Mark? Erik? Uli? Last chance to object.
Resolution 2008-11-19.2: We change the name of http://www.w3.org/MarkUp/Forms/specs/XForms1.2/modules/streamlined/index-all.html to "XForms for HTML"
Action 2008-11-19.2: John Boyer to rename onramp to "XForms for HTML" today.
Leigh Klotz: Before publishing this
as first WD I'd like to ask that you remove the namespace
declarations and namespace uses.
John Boyer: I can remove the instance
element as well and just show the data.
Action 2008-11-19.3: John Boyer to remove the namespace declarations and namespace uses from "XForms for HTML"
Mark Birbeck: John...I have been
asked by the XHTML 2 Working Group to get the XForms WG to reply to
this: http://lists.w3.org/Archives/Public/www-html/2008Oct/0011.html.
Would you be able to add that to the agenda?
John Boyer: Can you send that to the
list?
John Boyer: There are a couple of other points before first public WD.
John Boyer: We have pointed out the new way to set/get values. The setvalue operation modifies the value of the form control and then pushes the value into the recalculation.
John Boyer: There are a set of
submission attributes, esp. prune, source, target. Prune is an
interesting one. This is about pruning non-relevant data nodes. In
XForms 1.1, the name of that attribute is "relevant" and Steven
told us we would have trouble with that name. We now have @relevant
to imply a bind to a form control, so we can't re-use that same
attribute name on a input/@type='submit' element.
Paul Butcher: Could that name give us
trouble in the future? I assume it's boolean and perhaps we want
some other instrument for pruning.
Uli Lissé: [irc] would like to
propose @filter instead of @prune
Paul Butcher: It sounds active
John Boyer: Some prune=relevant by
keyword?
Paul Butcher: That makes sense. Isn't
the default to prune non-relevant stuff.
Leigh Klotz: So maybe we're thinking
about it backwards.
John Boyer: I see.
Leigh Klotz: So we could have both
prune and preserve.
Nick van: [irc] filter-relevant
John Boyer: For first public working
draft we could just drop it and put in an ed note.
Leigh Klotz: Or call it preserve with
saying it keeps it and leave the ed note.
John Boyer: We will have to pick this
up.
Mark Birbeck: XAML tends to have
attribute names that include something about their purpose...and I
now realise why. :)
Mark Birbeck: So it would be
@serialise-preserve, rather than @preserve.
John Boyer: There's quite a lot of
discussion so we'll just leave it to later. I'll take it out.
Leigh Klotz: Or just put in an
editorial note. The whole thing is a first draft anyway.
John Boyer: I'll put in a note.
John Boyer: If you attach this to a
form control and also to XForms namespaced elements, the ref
attribute could get used on input/@type='submit' to bind
it to data. The name that seemed to make the most sense is
source.
Leigh Klotz: src?
John Boyer: source avoids
the conflict with src
Paul Butcher: What Mark's put in about
the XAML names could this be longer?
John Boyer: So I can tag source,
target, and prune as attributes that are are in need of a better
name. We can put them on the agenda. Does that sound ok?
Action 2008-11-19.4: John Boyer to add editorial note about names to source, target, and prune to XForms for HTML.
John Boyer: These are just strings
that allow you to attach messages. They are a little
different.
Leigh Klotz: I have an alternate
suggestion: use the HTML label element and use some attribute value
on it to say alert/hint/help.
John Boyer: Then drop the label
attribute. That sounds good.
Mark Birbeck: That's not backward
compatible.
Mark Birbeck: could you explain
again? Not backwards-compatible, I'm afraid. Will mess up with
accessibility. Screen-reader will read alerts. :) And help. I.e.,
read stuff when it shouldn't.
Leigh Klotz: I don't understand.
They'll read them even when styled not to display?
Mark Birbeck: <label
type="alert">...</label>?
Leigh Klotz: <input
name='ssn' help='Put your
<b>SSN</> number here' />
John Boyer: If you need something more
than a string you probably need our alert element.
Mark Birbeck: But alert would need
@for.
John Boyer: It could inherit @for or
it could be a child element.
Mark Birbeck: But we also discussed
having @alertid as well as @alert.
Mark Birbeck: <input ...
@alertid="a" /?
Mark Birbeck: <div
id="a">...</div>
Mark Birbeck: I.e., you don't need an
alert element.
Mark Birbeck: You just need _any_
element.
Mark Birbeck: That's how many Ajax
libraries work.
Mark Birbeck: Point to a div that
becomes a message, in YUI.
John Boyer: If I look at Dojo, they
have their own name for alert.
Mark Birbeck: Yes, I agree.
John Boyer: So should we comment
this out or just put in an ed note? That seems like a good
approach.
Mark Birbeck: I'm only saying that
there is an intermediate step between (a) using @alert, and (c)
using <xf:alert>. I.e., (b) use @alertid.
John Boyer: Anyone prefer I comment
this section out or put in an ednote saying we're still working on
it.
Leigh Klotz: It's a first public WD so
we're working on everything. If you have a particular question you
can put it in an ednote.
John Boyer: I had no question.
John Boyer: These are the additional attributes to attach to select control. So it can give a combo box, for example.
John Boyer: I'd like to propose
that subject to the action items for today that we take this
document to first public WD.
Charlie Wiecha: We need a new
shortname.
John Boyer: We need the document at
the url.
Charlie Wiecha: So the name?
John Boyer: xforms-for-html-4?
Charlie Wiecha: Yes, I'd like to
discuss it.
Leigh Klotz: x4h4, x4h
Nick van: A bit cryptic
Charlie Wiecha: xf4h
John Boyer: Does anybody object to
xforms-for-html for the shortname?
John Boyer: Any objection to FPWD
under shortname xforms-for-html of next rev of sreamlined document
with actions from today done?
Nick van: [irc] shouldn't it be our
short name instead of streamlined
Resolution 2008-11-19.3: After completion of the action items for today that we take http://www.w3.org/MarkUp/Forms/specs/XForms1.2/modules/streamlined/index-all.html to first public WD under the shortname xforms-for-html