W3C Forms teleconference June 20, 2007

* Present

Mark Birbeck, x-port.net
Blake Jones, Daisy Consortium/ViewPlus Technologies
Erik Bruchez, Orbeon
John Boyer, IBM (chair)
Joern Turner, DreamLabs
Leigh Klotz, Xerox (minutes)
Rafael Benito, SATEC
Roger Perez, SATEC
Sebastian Schnitzenbaumer, DreamLabs
Steven Pemberton, CWI/W3C
Keith Wells, IBM
Uli Lissé, DreamLabs

* Agenda


* Previous minutes:

http://lists.w3.org/Archives/Public/public-forms/2007Jun/0020.html IRC supplement: http://www.w3.org/2007/06/06-forms-minutes.html

* Next F2F

John Boyer: The next F2F is in Madrid. The W3C has moved tech plenary has been to October 20, 2008. We had to move meetings back to accommodate. The dates are in the end of the 3rd day of the F2F minutes, but I'll list them here [reads].

* XForms Basic

Leigh Klotz: I have to send you the file and update the report to match Keith's new test suite, which I have to read, and then do implementation report.
John Boyer: Can you ask David and Kenneth about xsd:double and whether they support it?
Roger Perez: The devices don't support it.
Leigh Klotz: Devices that support J2ME support it.
Steven Pemberton: It's a normative change and our test suite doesn't check it. I'd prefer us to go to REC now and revise it if necessary. So record this as an issue and let's move on to get it out the door.
John Boyer: That sounds far; so don't let the xsd:double issue interfere with moving forward with XForms Basic 1.0.

* Summer Teleconferences

John Boyer: We should start planning our summer calls.

Action 2007-06-20.1: Steven Pemberton to create questionnaire to help with our planning calls around vacations.

* Remove half-detached notion from xforms delete action


John Boyer: It was seen as useful to see where deleted nodes came from, but there wasn't a particularly strong use case. There was some uneasiness about the half-detached wording; it sounded "hacky" and there was a feeling we should get rid of it in favor of some context information. Erik pointed out that the alternative we put forward doesn't hold water in the light of day. I propose that we scrap it.
Erik Bruchez: Would you keep the binding property?
John Boyer: That is a separate issue. I did some responses to that after the agenda. We can add that discussion to the agenda.
Erik Bruchez: Nodes without parents would be implementation dependent; I like the idea of having them around but people would try to access the parent.
John Boyer: The actual text in the event http://www.w3.org/TR/xforms11/#evt-delete says "Note that these nodes are no longer referenced by their parents." This sentence by itself is curious and could still be changed. It doesn't say anything about whether they reference their parents or not. Should we say no longer attached to the instance? No longer contained by the data model? That would completely sever the ties. Or leave it like it is?
Leigh Klotz: I thought we were scrapping it.
John Boyer: By "it" I meant the statement that deleted nodes refer to their parents. I think at one point I asked for more text to be there and I hadn't realized the text wasn't there.
Erik Bruchez: In DOM2 the removeChild method just says removes and returns it. At least in the spot I am reading, it doesn't say the child node loses the reference to the parent. It doesn't say. If we decide to keep it, we could be as vague as the DOM2 specification. "Removes the child node indicated by oldChild from the list of children, and returns it"
John Boyer: Yeah [warily]. OK, so is there anyone opposed to leaving the wording as it is here? "The instance data node deleted. Note that these nodes are no longer referenced by their parents."
Steven Pemberton: "is deleted"
Erik Bruchez: It says "returns the.."
Steven Pemberton: Nodes.
John Boyer: I'll fix that. If someone asks for the parent of the deleted nodes, will they or will they not get those parents? If we stay vague, then we can't count on it.
Erik Bruchez: It seems that the DOM spec doesn't require that the child nodes lose their reference to the parent. I'm not certain, but looking quickly at the spec... If we have doubts... Unless we are sure that DOM says one thing or another we shouldn't say anything.
John Boyer: We thought they still referred to parents.
Erik Bruchez: In the DOM specification in other places (clone, duplicate) it says it has no parents.
Leigh Klotz: We don't require DOM, though. Not all implementations in fact use DOM.
Erik Bruchez: Yes, XPath data model. I'm just looking for a clue. I doubt that that it is allowed in XPath to navigate to the detached node's parent but there is a way in JavaScript.
Mark Birbeck: What's the use case? It is a bit unusual.
John Boyer: We want to make the events useful with properties.
Mark Birbeck: Maybe a pre-delete event handler, and then a cancel. I can see a deleted event; display "your item has been successfully deleted." But manipulating deleted nodes is an odd use case. Why do we need to go overboard?
John Boyer: We got telecon minutes for years on why we don't have some of those other events.
Mark Birbeck: I'm not saying we should; I just say that I don't see a use case for these.
John Boyer: Maintenance of a parallel data structure; delete a person record from instance a, and I want to maintain a count in instance b.
Mark Birbeck: That seems odd that you'd base that on the instance nodes that have been deleted; I'd use the nodeset that I was about to do first.
John Boyer: That's an argument that says the xforms-insert and xforms-delete events are useless.
Mark Birbeck: As a notification.
Erik Bruchez: We have a use case where I was testing the name of the deleted event and know in the model that an employee has been deleted. I think it's a valid use case. Is returning the actual node the right way? Manipulating detached nodes in DOM is ok.
Mark Birbeck: It's not clear that this is useful.
John Boyer: This sounds like a last-call comment, Mark. We're asking whether deleted nodes should still retain a reference to their parents.
Mark Birbeck: It's not a DOM though.
John Boyer: It's a nodeset. The XPath data model doesn't say whether it has to be attached to a tree or not.
Mark Birbeck: It can't be.
John Boyer: The current text says the nodes are no longer referenced by their parents.
Erik Bruchez: I am starting to have a doubt about the XPath data model. It says that there is an element node for every element in the document. That's different from XPath 2.0 and DOM. I'm wondering if it is valid to return detached nodesets in XPath.
Mark Birbeck: That's why I am thinking of the use case; maybe before they are removed instead.
John Boyer: We already talked about why that's not going to work out. You are dispatching an event that says the nodes you are about to delete. If someone manipulates the DOM during that event, then the nodes you are about to delete may not be the right nodes anymore.
Mark Birbeck: If you have pointers to those nodes how can they change?
John Boyer: If someone deletes those nodes or inserts new ones that change what nodes match.
Mark Birbeck: You remove the selected nodes no matter what.
John Boyer: Yes. That's an alternative; we could revisit when you do it.
Erik Bruchez: It's on successful deletion now.
Leigh Klotz: How can it fail once you have the nodes?
Erik Bruchez: Perhaps it can't fail. It would be trivial in XPath 2.0. If I look at delete, in point 4, we say it is deleted. Before we perform the deletion we could send the event. That would be compatible with XForms 1.0. That would be incompatible
Leigh Klotz: Are there any practical consequences of this for XPath 1.0? If we break XForms 1.0-1.1 compatibility and then change again when we move to XPath 2.0 to use deleted nodes, is this the right way?
John Boyer: XPath is about immutable documents anyway. I think this is a CR, implementation question.
Leigh Klotz: I think you're right; it sounds like XPath 1 is underspecified.
Erik Bruchez: XPath 2 doesn't have nodesets. XPath 1 says that every node has parents. Right now in delete we're not saying the contrary, but it doesn't seem to allow us to say that an element can have a parent and not be a document.
John Boyer: What about switching DOMs and unions?
Erik Bruchez: Then you return a nodeset with five elements each in their own document.
Mark Birbeck: I think you can return the nodes that have been detached. You can remove them but not destroy them. The question is their parents. There may be some elements that you can't get to the tree. Maybe a minor wording change "These elements are not attached to the instance from which they were deleted."
Erik Bruchez: If we do that we do some cases that ... you shouldn't expect the behavior of navigating to the parent. It doesn't seem to be allowed.
Uli Lissé: I think it is allowed: from http://www.w3.org/TR/xpath#data-model Every node other than the root node has exactly one parent, which is either an element node or the root node. A root node or an element node is the parent of each of its child nodes.
Erik Bruchez: I found somewhere else. "There is an element node for every element in the document."
Leigh Klotz: But it doesn't say that there is a document for every element node.
Erik Bruchez: Maybe it's a hole in the spec.
Leigh Klotz: I think that's right. I think the implementers can tell us if they can't do it. We can't look to XPath 1 for answers because there aren't any and we're in mutations here which is outside XPath 1. We wait for XPath 2 to get more theoretical. If the implementations can do it the feature says in. I think it would be a cul de sac to over-specify this or proscribe it in advance of XPath 2 and we wait for CR.
John Boyer: Everybody OK with that?
Steven Pemberton: Yes.

Resolution 2007-06-20.1: For http://lists.w3.org/Archives/Public/public-forms/2007Jun/0053.html we decide the current wording is OK and await implementation feedback during CR from any implementations (particularly those not using at least DOM2 internally).

* Removal of first text node rule (first node rule is retained of course)

http://lists.w3.org/Archives/Public/public-forms/2007Jun/0052.html http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#ui-processing http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-setvalue

John Boyer: If the user modifies the string, we should replace the content of the element and you would lose the comment.
Erik Bruchez: Wasn't this decided during the F2F already.
Leigh Klotz: What was David Landwehr's conclusion?
John Boyer: He said that the issue was considered in 2004. The question was whole element or first text node. I responded saying that at the time it was clear it wasn't the whole element because of attributes. Since that time we've had a lot of discussion about the type MIP and whole node vs. node content; that third option wasn't considered or available.
Leigh Klotz: The type MIP could refer to the first text node as well. What is content?
John Boyer: There is a rigorous definition in XML http://www.w3.org/TR/2004/REC-xml-20040204/#sec-starttags Rule 43
Steven Pemberton: I'm in general in favor of making this changes but I have three questions. 1. Will it break any existing forms? 2. Where can you safely put comments that won't get lost. 3. Does anybody write it like this anyway?

Steven Pemberton: If you are using XForms to change an XHTML document, in general you'd like comments preserved.
John Boyer: If you want to refer to a particular text node, you can do that with XPath. Operating on that wouldn't do anything to the comments.
Erik Bruchez: Let's say you bind to a text node and the content is empty? Is that an empty text node or no control?
John Boyer: There's no empty text node in the XPath data model. If you're claiming it's the first text node and there isn't one, then what happens? It binds to the element and manipulates the content even if empty.
Erik Bruchez: The only use case for text node would be SGML content, a div, a text node, a span, a text node. The first-text node rule would let you get at the element before the span. So the first text node rule doesn't allow you to bind to the second one. So it seems like it's not working.

John Boyer: The only other issue that comes to mind is a real screw-case. If you write XPath predicates in your model that assign calculates based on the number of text nodes or the number of PIs within some element, here we have a case where setvalue and ui bindings would be doing something that technically requires a rebuild in order to get the correct values. So it would be one more thing in a dynamic predicate for model binding expressions.
Erik Bruchez: Wasn't that already the case? The calculate would depend on the setvalue?
John Boyer: That's a valid point that nobody had considered before; we already had this problem, but it's such a screw case that nobody had written before, counting text-nodes or PIs in simple content.
John Boyer: Does anyone on the call feel we need to talk about this issue further?
Erik Bruchez: I am in general in favor. It brings consistency between types and binding. The more difficult cases didn't work before anyway.
Leigh Klotz: I wish we had David or Kenneth here to explain their views.
John Boyer: David was the key person involved with Roland and he said in email we should read the email from Roland. I did and I responded that there was a third case, to talk about content of the element. The mixed-content case can be handled with more specific XPath. Otherwise, the main problem we had was that binding to the whole element caused trouble because elements could have attributes. I don't recall us really talking about a definition of "content" of the node we can rely on. In 2006 we came to the conclusion that that's how the type MIP had to operation for consistency with XML Schema. Now single-node bindings and setvalue really need to be manipulating the content, because of edge cases such as empty text nodes and divided text.
Leigh Klotz: One final question: with the element content definition, do we run into any mismatch between that and the Schema type validation with regard to whitespace handling?
John Boyer: I don't think so. Is anybody opposed to removing the wording for first-text node and replacing it with element content?

Resolution 2007-06-20.2: For http://lists.w3.org/Archives/Public/public-forms/2007Jun/0052.html we agree to change the wording for single-node binding and setvalue to "element content" as defined by http://lists.w3.org/Archives/Public/public-forms/2007Jun/0052.html (Rule 43) instead of the current first text node definition.

Action 2007-06-20.2: For http://lists.w3.org/Archives/Public/public-forms/2007Jun/0052.html John Boyer to propose spec-ready text for changing wording for single-node binding and setvalue to "element content" as defined by http://lists.w3.org/Archives/Public/public-forms/2007Jun/0052.html (Rule 43) instead of the current first text node definition.

* IRC Minutes


* Meeting Ends