RE: Namespace comments in XForms for HTML, was Re: Draft minutes for 2008-12-19 [includes resolution for FPWD for XForms for HTML]

In that case I fall back on my previous request to make the background colors for the HTML examples and the XForms+XHTML examples different.
Otherwise, namespace allergic readers who have been swayed by our smooth talk about XForms for HTML will encunter a document thick with namespaces and suffer anapylactic shock.

________________________________

From: public-forms-request@w3.org [mailto:public-forms-request@w3.org] On Behalf Of John Boyer
Sent: Friday, November 21, 2008 12:00 PM
To: Klotz, Leigh
Cc: public-forms@w3.org
Subject: Namespace comments in XForms for HTML, was Re: Draft minutes for 2008-12-19 [includes resolution for FPWD for XForms for HTML]



Although it was requested in the action item below [1] that I remove namespace declarations as being superfluous (i.e. only used in examples), I found that I could not remove the xf prefix.  So, I removed the other namespace prefixes for things like events and schema datatypes, but the xf namespace is used heavily in the normative content to talk about explicitly declared xf:model and xf:instance elements.  It is also used in the discussion of targeting events at the implicitly generated xf:model and xf:instance. Due to this latter point, it made more sense to retain the xf:instance declarations in the examples as well. 

[1] Action 2008-11-19.3: John Boyer to remove the namespace declarations and namespace uses from "XForms for HTML" 

The revised document is now available [2], and hopefully the amended version of the work described above will satisfactorily answer this action item. 

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 <http://www.ibm.com/developerworks/blogs/page/JohnBoyer> 
Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw <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 <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/0033.html>  http://lists.w3.org/Archives/Public/public-forms/2008Nov/0034.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 <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 <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 <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 <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 <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. <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 <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 <http://www.w3.org/2008/11/19-forms-minutes.html>  
* Meeting Ends