Blake Jones, Daisy/ViewPlus
Nick van den Bleeken, Inventive Designers
Leigh Klotz, Xerox (minutes)
John Boyer, IBM (chair)
Lars Opperman, Sun
Uli Lissé, DreamLabs
Joern Turner, DreamLabs
Mark Birbeck, x-port.net
Rafael Benito, SATEC
Roger Sanchez, SATEC
Sebastian Schnitzenbaumer, DreamLabs
Steven Pemberton, CWI/W3C
Keith Wells, IBM
Charlie Wiecha, IBM
Erik Bruchez, Orbeon (:45)
John Boyer: The review period ended
August 31; we should be pushing it forward.
Steven Pemberton: Let me look at the
replies.
John Boyer: The replies were still
coming in on XForms 1.1, nothing on the errata for 1.0. The
readonly issue got mentioned; I think it was hairy enough to
resolve for 1.1 (whether readonly applies to actions or not). If we
ever want to backport that solution to 1.0, it's not 1.0 TE. There
was no feedback on any of the errata, which I understand is what we
should be looking for for an edited recommendation.
Steven Pemberton: Sure. I'll
check.
Action 2007-10-10.1: Steven Pemberton to push XForms 1.0 TE PER through to REC.
John Boyer: Do I need to regenerate
the spec and do pub rules?
Steven Pemberton: It just needs a
different status.
John Boyer: Usually I do that with
specxml. Do we have to get on the director's calendar to advance to
recommendation?
Steven Pemberton: Let me check the
steps now...I don't see any reason for a meeting. I'll send a
message.
Action 2007-10-10.2: John Boyer to generate new status section, REC, date, and empty errata page, pubrules check for XForms 1.0 TE PR.
John Boyer: Do we need a resolution
from the group?
Steven Pemberton: I don't think so; we
proposed it as an edited recommendation. After that's there's the
AC vote and there's nothing more for the group to do.
John Boyer: We're still working on
last-call issues; there are other things to be done. We need a
report of the last-call issues and their disposition. Does Shane's
system produce that?
Sebastian Schnitzenbaumer: [irc]
yes
Steven Pemberton: Yes, it's
automatically generated in the W3C format.
Nick van: [irc] we prob. need to
update the user state
John Boyer: What do we do if there is
no response?
Steven Pemberton: There's a rule for
that: silence is consent.
John Boyer: Someone is updated the
last-call system with the newer emails that were part of the thread
around IRIs. Does anyone know who is doing that?
Steven Pemberton: By email.
John Boyer: It's because of reply
all?
Steven Pemberton: That may be it. The
xforms-issues mailing address goes to incoming unless it has an
issue number in the subject, in which case it gets appended to the
issue.
John Boyer: So the email responses
aren't containing those issue numbers. So I can trash them as
already resolved (they're happy with xsd:anyURI).
Leigh Klotz: I entered titles,
descriptions, etc. I made up bios and pictures for people who
didn't send them.
Mark Birbeck: I have a speaker
profile. I tried to merge it.
Leigh Klotz: OK, please send me the
link and I'll try to do it or we can let Dave Megginson know and he
can do it.
John Boyer: Charlie says it's in progress.
Uli Lissé: I made progress
but am not finished.
John Boyer: Estimated time?
Uli Lissé: I hope
tonight.
John Boyer: Thank you. Do you like the
formatting/
Uli Lissé: Yes, it's much
better than before.
John Boyer: Steven, you did some
submission examples.
Steven Pemberton: Yes, I sent
then.
John Boyer: The action attributes
should go to resource.
Steven Pemberton: That's a good
discussion, but it's editorial.
John Boyer: As long as that's OK. It's
deprecated for 1.1
Steven Pemberton: I thought we had an
outstanding issue for that?
John Boyer: No, that's for if.
Steven Pemberton: OK.
John Boyer: And there are no
suggestions about where to put these.
Steven Pemberton: I thought that was
for a last-call comment
John Boyer: Yes, "chapter 11 is really
long and has no examples."
Steven Pemberton: Yes, at the
beginning.
John Boyer: Can you do the
specXML?
Steven Pemberton: ...
Leigh Klotz: I'll do it.
John Boyer: Do you recall having an
example for submit-done?
Steven Pemberton: I haven't done
anything on catching events; just the submission element.
John Boyer: Maybe Erik's feedback,
linked in the agenda, says SOAP example as well. I can probably
pull one of those together. It might have a submit-done handler in
it. So you did intro-type examples.
Steven Pemberton: Yes, just to
illustrate the section. It gives examples of the major
features.
John Boyer: I recall a file as
well.
Steven Pemberton: Yes, instance,
etc.
John Boyer: So the token's over to
Leigh now.
Action 2007-10-10.3: Leigh Klotz to update Steven Pemberton's submission examples and convert them to spec xml.
Leigh Klotz: I think we should let
them know we're interested in this and ask for XForms to be
included. It's useful for us, and it's sufficiently general that we
ought t.
John Boyer: What's the timeframe? Can
we do this at a F2F?
Leigh Klotz: There's no timeframe
listed; it's a WD, but we should send them a note.
Lars Opperman: Doesn't this apply to
HTML forms as well.
Leigh Klotz: ...
John Boyer: So we should send a note
and I should put it on the agenda. Leigh, can you send the
note?
Leigh Klotz: Sure.
Action 2007-10-10.4: Leigh Klotz to send note about http://lists.w3.org/Archives/Public/public-forms/2007Oct/0002.html to appropriate WG.
Action 2007-10-10.5: John Boyer to add one hour to F2F agenda to discuss http://lists.w3.org/Archives/Public/public-forms/2007Oct/0002.html
John Boyer: I called this "readonly
as firewall." Nick responded with a subtlety. I assumed that if a
node existed and was readonly, you couldn't delete it or replace
it; whereas if you're going to insert it, you don't know. Nick is
saying we should do the same parent check on delete and
replace.
Leigh Klotz: This is a shift from leaf
nodes with inheritance to complex nodes.
John Boyer: That's the big issue; we
already have that.
Leigh Klotz: I guess with select we
change complex nodes.
Nick van: If the parent isn't readonly
you can change the parent.
John Boyer: So you're saying readonly
is about the content of the node.
Nick van: The node itself would be
deleted from the parent. It becomes a subtree without a parent, but
you don't change the node itself.
John Boyer: If a node is readonly but
its parent isn't readonly, you want to be able to delete it or
replace it.
Nick van: That's what I think; if
everybody else thinks otherwise it's ok. In my view, you don't
change the node if you delete it.
John Boyer: Right. So, if a parent is
readonly, it doesn't matter if it's an element or an attribute, you
couldn't delete it.
Nick van: Yes.
John Boyer: So it's about the content
and attribute of a node, but not the node itself.
Nick van: You do have to change the
parent pointer, but conceptually, yes.
John Boyer: So we just need to pick a
way. Is there anyone who's unclear about the choice?
Leigh Klotz: Do you have a reason for
picking the route you did?
John Boyer: For me, the node is
readonly. relevant doesn't apply to the content and attributes of a
node. Making it disappear seems like a change to me. I hadn't seen
there was another way to look at it until Nick brought it up.
John Boyer: <bind nodeset="x"
readonly="true()"&/gt; Can you delete or replace
x?
Nick van: if parent of x is not
readonly.
John Boyer: Or in Nick's view, suppose
x contains element y, then you could delete x but not y.
John Boyer: in my case, you can't
delete x, nor y (because y is readonly if its parent is
readonly)
Mark Birbeck: I've lost track of the
current state. If x has an attribute of y is it also readonly? Are
we binding to the node x or the first child text node?
John Boyer: readonly binds to node
itself. We've uniformly stepped away from the first child text
node.
Mark Birbeck: Not on controls
though.
John Boyer: On controls. It binds to
the whole content of that node.
Mark Birbeck: To the text node?
John Boyer: The binding of x causes
the entire content of x to be replaced.
Mark Birbeck: But not the
attributes
John Boyer: So you have a new single
text node containing the modified value.
Mark Birbeck: So I should have said
content.
Erik Bruchez: [joins]
Mark Birbeck: ...attributes... I have
kind of missed it then.
John Boyer: All the MIPs apply to the
nodes; when you bind relevant, it makes the entire node relevant.
Same for readonly. When a form control binds to a node, it gets its
readonly-ness from x, not from children. When a form control writes
to a data model, it does it in a manner consistent with setvalue.
So it replaces the content of x with the value. The reading or
writing of the content is specific to the value of the node; for
MIPs and events, it's the nodes themselves.
Mark Birbeck: That's OK. There've been
so many discussions I've lost track.
John Boyer: OK. So when you say
<bind nodeset="x" readonly="true()"&/gt; any
nodes that have x as an ancestor become readonly because of the
inheritance rules for readonly. So all attributes and nodes within
its content.
Leigh Klotz: So how do you make an
element be readonly but not an attribute.
John Boyer: nodeset=x/*.
Mark Birbeck: @*
Leigh Klotz: I want @* false.
Roger Sanchez: [irc] good question
Leigh.
John Boyer: <nodeset="x/node()"
readonly="true()"> The a
John Boyer: Or just x/* for the
elements.
Leigh Klotz: so x/* wouldn't set the
text to be readonly.
John Boyer: actually, use node() if
you want more than elements.
Nick van: So the text wouldn't be
readonly.
John Boyer: I see, for a leaf node,
you want to make the content readonly but not the attributes. I
don't think we have a way of doing it.
Leigh Klotz: Can you do it with
text?
John Boyer: Then you don't get the
readonly indicator on the form control.
Mark Birbeck: Or you could use a bind
statement.
John Boyer: <input ref="x" > but
<bind nodeset="x/text()" readonly="true()"> can you replace
the text? Because replacing the text isn't a change to the
node.
Nick van: I think you can change it by
the same reason that it is allowed to delete a readonly node if the
parent is not readonly.
John Boyer: To some extent that
depends on how you implement setvalue; if it changes the string of
a text node, then a form control could not modify that text, but if
you replace the text node.
Leigh Klotz: Don't do that.
John Boyer: The only way to implement
that in the xpath data model is to destroy the text node if there
is empty text.
Nick van: A PI is also replaced so you
can't just do a string replace if there are children and then
append the new text.
John Boyer: So that fixes that problem
entirely.
Nick van: But if we go for this, then
I think it contradicts the way we now specify delete of nodes,
because we say you can't delete a node if the parent is
readwrite.
Leigh Klotz: If a parent is readwrite
you can't delete its children?
Nick van: Yes, I think it's a typo.
But John said it was written on purpose like that.
John Boyer: Delete says you cannot
delete a node if it is readonly but its parent is readwrite.
Nick van: If you can't delete readonly
children then you can't delete readonly children so you can't
delete them all.
Mark Birbeck: You must be able to.
Every child is going to have a parent that is readwrite,
somewhere.
John Boyer: You could make the root
readonly.
Mark Birbeck: ...
Charlie Wiecha: The container model.
It makes sense to allow deletion of readonly nodes if the parent is
readwrite.
John Boyer: [irc] Do we want to be
able to delete a readonly child of a readwrite parent?
Mark Birbeck: How do you protect a
node from being readonly then? The parent is readwrite.
John Boyer: Even if the grandparent is
readonly you can't delete the node.
Nick van: So you couldn't delete a
node if its children.
Mark Birbeck: So you inherit it from
your children?
John Boyer: Here's the bullet 4:
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-delete
John Boyer: Now it says you can't
delete a readonly node; the proposal is you can't delete nodes from
readonly parents.
Nick van: So you say you cannot be
deleted if a parent is readonly. But if you delete the parent then
you can delete it anyway.
John Boyer: Is anybody opposed to this
change? Sounds like a resolution to me.
Nick van: And for submission as
well?
John Boyer: Delete and replace should
act the same.
Nick van: readonly-ness inherits so if
an ancestor is readonly then the parent is readonly.
Resolution 2007-10-10.1: Deletion or replacement of a node (subtree) is forbidden if the parent of a node is readonly, but allowed if only the node itself is readonly.
Action 2007-10-10.6: John Boyer to implement resolution that deletion or replacement of a node (subtree) is forbidden if the parent of a node is readonly, but allowed if only the node itself is readonly.