Re: Draft minutes for 2008-12-19 [includes resolution for FPWD for XForms for HTML]

In the minutes, I don't believe that we got to the point of deciding to do 
the following action item:
Action 2008-11-19.5: John Boyer to change XForms for HTML to drop label 
attribute and move alert/hint/help to attribute values on some attribute 
on element label.
This action item appears immediately after Mark Birbeck points out that it 
would not be backwards compatible to do so.
I thought we got to the point where it was clear that the attributes given 
in the spec were actually good, e.g. an alert attribute directly on a form 
control is much like what is done in popular ajax libraries like dojo.  We 
did discuss the possibility that there could be further useful attributes, 
but we did not get to the point of deciding what those might be.  Instead, 
the decision was to go to FPWD with the attributes as given since changes 
can be made in future working drafts.

The net of this is that I think the above action item should be removed 
from the minutes.

Thanks,
John M. Boyer, Ph.D.
STSM, Interactive Documents and Web 2.0 Applications
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw





From:
"Leigh L. Klotz, Jr." <Leigh.Klotz@Xerox.com>
To:
public-forms@w3.org
Date:
11/19/2008 09:29 AM
Subject:
Draft minutes for 2008-12-19 [includes resolution for FPWD for XForms  for 
HTML]



Please respond with corrections.
Please start new threads for discussion.

W3C Forms teleconference November 19, 2008
* Present
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
* Agenda
http://lists.w3.org/Archives/Public/public-forms/2008Nov/0039.html 
Next FtF (Restrictions on W3C team travel)
Cross-browser impl report for FF extension
1.0 Basic impl report?
boolean-from-string() issue
Streamlined syntax module
XForms for HTML First Public Working Draft
IRC Log
Meeting Ends
* Next FtF (Restrictions on W3C team travel)
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.
* Cross-browser impl report for FF extension
Keith Wells: I am working on it. I'm having some trouble.
* 1.0 Basic impl report?
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.
* boolean-from-string() issue
http://lists.w3.org/Archives/Public/public-forms/2008Nov/0033.html 
http://lists.w3.org/Archives/Public/public-forms/2008Nov/0034.html 
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.
* Streamlined syntax module
http://www.w3.org/MarkUp/Forms/specs/XForms1.2/modules/streamlined/index-all.html 

John Boyer: I've renamed it XFormsA; there's been discussion about other 
names. Other names that have come up
XForms Transitional (that's what's in our charter) 
XForms Basic
XForms Tiny
XFormsA
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.
** set/get values
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.
** submission attribute prune
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.
** submission attribute for portion of data
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.
** label/alert/hint/help
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.
Action 2008-11-19.5: John Boyer to change XForms for HTML to drop label 
attribute and move alert/hint/help to attribute values on some attribute 
on element label.
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 &lt;b&gt;SSN&lt;/&gt; 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.
** selection, multiple, appearance
John Boyer: These are the additional attributes to attach to select 
control. So it can give a combo box, for example.
** Summary
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?
* XForms for HTML First Public Working Draft
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
* IRC Log
http://www.w3.org/2008/11/19-forms-minutes.html 
* Meeting Ends