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
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].
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.
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.
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).
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.