See also: IRC log
<scribe> Scribe: John_Boyer
trackbot, start telecon
<trackbot> Meeting: Forms Working Group Teleconference
<trackbot> Date: 02 May 2012
Erik: sent a note to public list
for review after last telecon
... implemented something for the edge cases but need to know
if it is the right thing while rewriting some of that code
<ebruchez> http://lists.w3.org/Archives/Public/public-forms/2012Apr/0059.html
Erik: Asks John to confirm summary
John: Agrees yes, spec wasn't really intended to limit binding to edge case node types (actual text nodes, PIs, comments) since it is possible to express in XPath
Erik: According to XML Schema
literature, comments and PIs are ignored in validation
... even though spec says data binding restrictions say "simple
content", understanding is that it was not intent to restrict
binding to the edge case nodes
John: although schema technically
won't validate the edge case node types, nothing in spec
prevents you from attaching those simple types to nodes using a
type MIP
... You proposed some wording for a note and asked if any
thoughts. I read and thought "wording looks good, can sweat
words on telecon" and "could put this in the common form
controls section rather than in every form control"
Erik: it might be a bit hard to implementers to find when reading details about a control
John: Could lengthen the description slightly in each data binding restriction itself
http://www.w3.org/TR/xforms11/#ui-input
John: restriction says "Binds to
any simpleContent"
... what could be said differently
Erik: had difficulty determining what simpleContent meant.
Philip: I always read that as being what is defined in XML Schema
<ebruchez> http://www.xqueryfunctions.com/xq/functx_has-simple-content.html
Erik: it is a lot to ask
implementers to read the schema spec to figure this out; I
didn't want to spend days doing it
... this link (above) is not normative but I trust the
author
... a node needs to have character data in order to be simple
content
... does an input bind to simple content if the element is
empty?
Philip: If you define whitespace as significant, does that change your technical point? Because whitespace is usually insignificant in DOM.
Erik: I don't know. It might be a tree construction to remove the whitespace text nodes, but in my implementation we get whitespace text nodes.
John: Based on XPath data model, whitespace is significant. Also, pure xpath data model says no such thing as empty text node.
Erik: DOM does allow you to create empties
John: Agree and currently we do create empties so that there is no change of node existence on a setvalue, whether or not empty string happens, but I was considering ways to not create empty text nodes (even though I might not delete them once they exist)
Erik: xpath also says merge adjacent text nodes, whereas DOM doesn't
John: in XML schema validation, non-adjacent text nodes (e.g. separated by PIs) are merged for validatoin
Erik: so you get different
results based on whether you bind to a PI/comment/text node
versus a containing element
... any thoughts on how to clarify the data binding
restriction
John: it doesn't quite say what we mean, because we mean binding to a node that conforms to simpleContent restriction, but I didn't see it as a problem
Erik: implementers will be fairly
familiar with the term node, so we could add something that
includes that word.
... is it even correct to say we bind to the content?
John: No, "we don't say quite what we mean" since we bind to the node whose content conforms...
Erik: So that's when I started reading about that function and that made it harder to decide what to implement
John: intention at the time was
to reference XML schema
... at the time we were distinguishing binding to complex types
that contained text versus those that contained nested
elements.
Erik: Yeah and for years I've read it that way, but I'm now in the situation of having to decide what to do with edge case nodes where it is not clear that the definitions of XML schema apply
John: we thought it was clear
enough because we applied them to the node that is referenced
in the binding
... the low priority of the issue of binding to edge case nodes
combined with the relative clarity of those nodes containing
text content and not nested elements caused us to move on
... I don't have a readily available way to efficiently clarify
this in a phrase added to each data binding restriction
Erik: we could fairly quickly enumerate the cases in a note like the one I put in the email
John: Actually spec says that binding to comments and PIs has undefined behavior
http://www.w3.org/TR/xforms11/#ui-processing
Erik: I was thinking that the Note would be added in this section anyway, except we could just add it to XForms 2.0 and it doesn't need to be an erratum
John: It's wiki spec for first public working draft, and the note is a consistent expansion of what is there, so safe to add now. Want to add it?
Philip: reach the top of the hour, done?
<scribe> ACTION: Erik to add the note from the email to the ui-processing section in the XForms 2.0 wiki spec. [recorded in http://www.w3.org/2012/05/02-forms-minutes.html#action01]
<trackbot> Created ACTION-1900 - Add the note from the email to the ui-processing section in the XForms 2.0 wiki spec. [on Erik Bruchez - due 2012-05-09].
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: John_Boyer Inferring ScribeNick: John_Boyer Default Present: pfennell, ebruchez, John_Boyer Present: pfennell ebruchez John_Boyer Regrets: Steven Nick Agenda: http://lists.w3.org/Archives/Public/public-forms/2012May/0001.html Found Date: 02 May 2012 Guessing minutes URL: http://www.w3.org/2012/05/02-forms-minutes.html People with action items: erik WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]