W3C Forms teleconference May 28, 2008

* Present

Charlie Wiecha, IBM
John Boyer, IBM (chair)
Leigh Klotz, Xerox (minutes)
Nick van den Bleeken, Inventive Designers
Roger Pérez, SATEC
Doug Scheppers, W3C
Steven Pemberton, CWI/W3C
Uli Lissé, DreamLabs
Keith Wells, IBM
Mark Birbeck, x-port.net

* Agenda


* Previous Minutes

Previous minutes:

* Rich Web Application Backplane

John Boyer: Another call this Friday.

* Action Item List


Steven Pemberton: I've got the list of done stuff to send to Nick.
John Boyer: We only have a little time to the F2F meeting. I'm disappointed to report I don't have any done myself.

* Next FtF (June 9-12, Amsterdam)


John Boyer: Thank you John.
Steven Pemberton: Four days.
John Boyer: We have six indicated every day, and one remotely.
Steven Pemberton: It's question of how many Skype connections we need.
John Boyer: There are others who aren't on the list, at least two more.
Charlie Wiecha: I will.
John Boyer: So nine or ten all together.

* Expression dependencies and dynamic dependencies


John Boyer: Is Nick here?
Leigh Klotz: It looks like he's idle.
John Boyer: What does "NameTest" mean? I think what we ended up with, two Septembers ago, is that as an XPath expression is getting evaluated, any time we match a NameTest, we add that node to the list of nodes that are being referred to by the XPath expression. I think we did that so there would be more responsiveness of the compute system to predicate changes ("dynamic"), so if certain changes to the XPath happened, the various calculations would be able to detect that a change of referencing it happened and would know to get recalculated. Nick has an example, and has run into some problems. If you execute the XPath expression he gives, you'll notice that it matches both of the a nodes; if you read the expression from left to right, and look at the predicate next to the a, you'll notice it's trying to match a whose attr value is X, but the way we've written the spec, it puts a in with x. So if any of the a elements change, we respond to that; more importantly, if any of the attr nodes in any of the a's change, we'll respond to that as well, and that's part of the key. For any a value that we match, we have a NameTest against each of those attributes as well, so all of the nodes that feed a predicate are considered. This seemed like a good idea. The alternative was that we would only register the register as dependencies those identified by a completed Location Step of an XPath expression, so from the predicate of the first a step we might record only the element a that matched the predicate. So the question was should we record only the matched nodes, or feed in all those that are tested. We went with the broader test, the one that keeps all references; that means we will follow all calculations. If you notice in the a element, if you imagine that being changed to X, we detect that change and re-run whatever calculates might have that full expression; whereas with narrower references (location step) only the a that has attribute X would have been recorded and if you change the value Z it would not have known to re-evaluate itself.

Nick van: [joins]
John Boyer: Nick points out that that doesn't get us very far, that if you look at the second location step of the XPath expression, because the prior location step that selected that a, it only goes into the first a child, so by the time you get into the b's, you're only matching the b node that is in the first a, not both a's. So this XPath expression is not setting up enough dependencies. So technically this expression doesn't set up any dependencies.
Nick van: [irc] John thank you for explaining it so well.
John Boyer: Thanks. I don't have the earlier link, which was a related problem with the use of @id attributes.

Nick van: You get circular dependencies if multiple elements have calculates based on the other ones. http://lists.w3.org/Archives/Public/public-forms/2008Apr/0086.html
John Boyer: So the creation of the extra dependencies seems to solve a responsiveness problem if you look only one level deep. So maybe it's an 80/20 rule. XPath expressions run left-to-right, for better or for worse. So we have a choice: do we stick with the current plan and resolve that the issue that Nick raised is a problem.
Leigh Klotz: If we expand the number of references made, does that lead to circular dependencies?
John Boyer: We decided already on the expanded references; the spec didn't say that constituted a reference. So we had a choice at that time, and some people thought that the way a dependency was established was based on the set of nodes that were referenced at the end of a location path.
Mark Birbeck: [joins]
Nick van: [irc] I don't like to drop does extra dependencies, because I hate to add a rebuild to fix it
John Boyer: Other people thought it was every time you matched a name test. The group decided that it was every name test. With the narrow definition of leaf nodes by whole location paths, you end up having to do more rebuilds of the compute system in order to get the compute system to fire; if you start making changes to nodes that cause them to match, that causes you to have to do rebuilds.
John Boyer: If you look at a[@attr=X], you only end up getting the one @attr that corresponds to the a node that is selected. The issue wasn't clear but the whole expression is a locationpath. You might just think it's the c nodes, not all the attributes. So if any c node changed, we'd re-run the XPath. What we went with was that all the NameTest things we match along the way, we'll re-run that calculate to see which c we need to use. That seemed to be useful; it solved a class of non-responsiveness problems.
John Boyer: However, for this example, it creates too many dependencies.
Leigh Klotz: Do you see a way we can do it better in a next version?
John Boyer: Yes, sort of. If we had a narrower definition of what constituted an actual, strict dependency, from the standpoint of detecting strict dependencies, we could use the expanded definition to automatically detect when we have to do rebuilds. We could say narrowly that the recalculate algorithm operates over a different set of dependencies that rebuild does. We could fix this and make it still responsive, without the form author having to write rebuilds.
Leigh Klotz: And that would eliminate the false circular dependencies?
John Boyer: I think so. Because the circular dependencies happen in recalculate and the rebuild would be done with expanded references. When the core recalculate topological sort runs, it wouldn't have so many false dependencies. So we could fix this in a future version by having two sets of dependencies.
Leigh Klotz: Or coloring them.
John Boyer: Yes, weak and strong.
Nick van: [irc] for the record, I don't have anything against the current wording, it adds the correct nodes to the dependency list in most cases I guess. And personally I only would like only to make changes if the change that __doesn't__ add extra cases where a manual rebuild is necessary. (but this is what John is saying also)

Charlie Wiecha: So anything else we do here is going to be fairly ad hoc.
John Boyer: Unless we do it in some careful way, we would break something. I don't see a way to do this other that.
Leigh Klotz: Could we put this into 1.2 or is it too far along?
John Boyer: There's much lower-hanging fruit deferred out of 1.2. It seems like a style of instance data we just can't support right now. It looks like it works but it doesn't.
Nick van: [irc] I agree with that
Uli Lissé: [irc] i would like to keep the current behaviour, because this way can handle some dynamic dependencies just by static analysis
John Boyer: http://lists.w3.org/Archives/Public/public-forms/2008Apr/0086.html
John Boyer: The only way to handle this style of instance is to have a more intelligent authoring.
John Boyer: Can you live with deferring this to 2.0 or whenever, and document it for now?
Nick van: Yes, it's fine for me. I cam across it when upgrading the XPath engine in Chiba?
Charlie Wiecha: There may be several dependencies; perhaps a note that gets inserted into the spec. Maybe it's already there.
John Boyer: Because it creates circular dependencies. Or do we just put it in the mail archive? This one seems like it should work.
Charlie Wiecha: I mean the original.
John Boyer: I know that we have a fairly exhaustive explanation of which dependencies get created an which don't.
Charlie Wiecha: Maybe that's sufficient.
John Boyer: Then I should check to see if a further comment or example needs to be made out of the parent/child issue out of http://lists.w3.org/Archives/Public/public-forms/2008Apr/0100.html as that's just an editorial change. It's a good point that if you go one location step further down the path, you're not getting all the b's from all the a's, but only all those that matched the first step.
Charlie Wiecha: Or all the a's.
John Boyer: The NameTest matches all the a's and the predicate matches their attributes. But you cannot then say about all the b's. So it only matches the b children within the matched a.

Action 2008-05-28.1: John Boyer to write a clarifying note in XForms 1.1 regarding dependencies and http://lists.w3.org/Archives/Public/public-forms/2008Apr/0100.html and http://lists.w3.org/Archives/Public/public-forms/2008Apr/0100.html

* UIInline


John Boyer: Erik is asking when a host language can add their own stuff, do we mean that they can add their own inline stuff or their own anything?
Nick van: I would expect also block-level elements
Steven Pemberton: Well, inline is a property of CSS, not the markup.
Mark Birbeck: In XHTML we have inline schema elements and block schema elements.
Steven Pemberton: We deliberately renamed them so there was no there was no confusion; CSS took our names inline and block. So we renamed them structure and text, to get away from that implicit linking between the CSS and the markup. So I'm not quite sure what the question is. Is the question that you aren't allowed anything to be disply:block within a hint?
John Boyer: Yes
Steven Pemberton: We don't have any control over that.
John Boyer: I think so too. I thought ui-inline was just a name that we gave for allowing mixed content. I think the name is a problem and that's why Erik is having confusion over whether he can put block-level stuff.
Steven Pemberton: It really doesn't matter.
John Boyer: Is there some alternative name?
Steven Pemberton: We have "text" and "structure" in XHTML.
Nick van: UI.textOrStructureOrAnything
John Boyer: So UI is confusing as well.
Steven Pemberton: I think that's called "flow" in XHTML.
Mark Birbeck: I was going to suggest "flow."
John Boyer: So UI.Flow
Steven Pemberton: Works for me.
Mark Birbeck: Works for me.
John Boyer: Is that an editorial change?
Steven Pemberton: It doesn't change any normative aspect, just a renaming.
John Boyer: OK.

Action 2008-05-28.2: John Boyer to change XForms 1.1 document and Schema to rename UI.Inline and UI.Content.Extension as a non-normative, editorial change.

John Boyer: UI.Contents?
Mark Birbeck: "Content" is one of those general words that we might regret.
John Boyer: Content is what we put in.
Mark Birbeck: Is it currently empty?
John Boyer: No, Char data and XForms outputs. And by comment, host languages can add their own stuff.
Mark Birbeck: In XHTML Modularization, we don't say you can modify it; we have another Schema type, called UI.Content.Extension which is empty and the host-language would redefine that. So UI.Content would contain xf:output and UI.Content.Extension. That might make it clearer.

* Spec reviews needed


John Boyer: There are three specs that seem to need people from our group to review. The most important part is XmlHttpRequest is in last call; they're giving us extra time for our F2F. Can anyone produce a review and a set of comments?
Charlie Wiecha: I can do that.
Steven Pemberton: http://www.w3.org/TR/2008/WD-XMLHttpRequest-20080415/
Steven Pemberton: Mark?
Mark Birbeck: I can do that.
Charlie Wiecha: I can take events then.

Action 2008-05-28.3: Mark Birbeck to review http://www.w3.org/TR/2008/WD-XMLHttpRequest-20080415/ and present straw set of comments for discussion and approval at F2F.

Action 2008-05-28.4: Charlie Wiecha to review http://www.w3.org/TR/2007/WD-xml-events-20070216/ and present straw set of comments for discussion and approval at F2F.

John Boyer: And the CURIE spec; we can't get Mark or Steven to review it.
Steven Pemberton: CURIEs is a syntax for compact URIs, and it is a replacement for QNames in attributes, because there are URIs you cannot contract using QNames. It's a short spec and ideal for anybody interested in URIs. The problem emerges from RDFa because we want to be able to say dc:creator and that's a shorthand for a full URI, but if we use the QName spec, some can't be shortened that way, so we allow anything else after the colon, so you can shorten any URI. There are plenty of other places where W3C uses QNames where they ought to be using URIs. I don't think it will arise in XForms.
John Boyer: Only when CURIEs take over QNames in XPath.
Mark Birbeck: @appearance, message/@level.
John Boyer: So it could possibly be used by us in the future.

Steven Pemberton: If you were to ask me who would be a good person to review it, I think it would be Leigh.
Mark Birbeck: ...
John Boyer: The dividing line for us is whether the name as a colon. We allow anything else that's qname-but-not-ncname and we interpret that specially. In those cases it doesn't matter whether it's a CURIE or QName as the key is a colon.

John Boyer: Leigh, you've been pseudo-volunteered.
Leigh Klotz: When is it due?
Steven Pemberton: Fairly short; last call started and it closes June 10th. http://www.w3.org/TR/2008/WD-curie-20080506/
Leigh Klotz: So our comments better be brief.

Action 2008-05-28.5: Leigh Klotz to review http://www.w3.org/TR/2008/WD-curie-20080506/ by June 10th.

* Announcements


John Boyer: There's a new XForms Builder from Orbeon. Steven, can you put that in the Wiki?
Steven Pemberton: And a blog, perhaps, as we quite like the one for RDFa.
John Boyer: Is there any way to get a feed of the blog to show up on the home page? We said the announcements would go in the wiki, but then there was a question of what constitutes an announcement. So if the blog were somehow opened up to all members. So can we put the content on the home page?
Mark Birbeck: Maybe we can use the feed for planet xforms instead? We could refer people there? http://planetxforms.org/ Or as Steven says, feed back into Planet XForms.
John Boyer: Can we get this on our home page by whatever strategy you think is best? http://lists.w3.org/Archives/Public/public-forms/2008May/0043.html
Steven Pemberton: OK.

Leigh Klotz: The real question is not a blog, but how to get generated content onto the home page.
Mark Birbeck: I guess the question is to work out what we're trying to achieve. If we want to get across activity, then point at planetxforms, and updating it manually isn't that much work.
Leigh Klotz: There's no question; we should have a link to planetxforms if we don't. Updating it manually every so often is the status quo.
John Boyer: Steven, while you're in the neighborhood, can you pop in a link to planetxforms as well?
Steven Pemberton: Yes.

* Forms Task Force

http://lists.w3.org/Archives/Public/public-forms/2008May/0061.html http://lists.w3.org/Archives/Public/public-forms/2008May/0060.html

John Boyer: Task force members are Nick, Keith, and Mark.
Nick van: [irc] I started to write XForms 1.2 spec text, and it is taking quite some time to just change anything, probably bcz. it is the first time, so I don't think I will have much time beside that before the ftf.
John Boyer: Maciej responded with architectural principles; we need to engage them.
Keith Wells: Reading through the possible responses, some of it becomes overwhelming quickly. So what is our goal? ...

John Boyer: One reason is that I could have one long mail spawn a bunch of shorter emails.
Mark Birbeck: I've been working on Ubiquity.
Keith Wells: The transformer tool on sourceforge is a good start point; it takes XHTML markup and produces XForms markup. I talked to Roman Huditsch about the license and it's OK.
Leigh Klotz: I think posting something about Ubiquity and its examples is a good plan. I see that Google has noted they now host versions of various Javascript libraries http://ostatic.com/163191-blog/google-now-hosts-open-source-libraries and in fact they also host Ubiquity XForms as well, so Mark should just show how that works, as he has proposed.

Mark Birbeck: I've also had interest from one of the big Ajax library creators, who has their own XML language. (Interest to add people to work on the library, that is.)

Steven Pemberton: We don't have an announcement of Ubiquity on our homepage either

* XForms 1.1

Progress on implementation reports?

John Boyer: Mark, do you have a report?
Mark Birbeck: Ubiquity is our priority right now. Were you hoping to have a test quite?
John Boyer: We need implementation reports on XForms 1.1; it isn't a done deal until PR.

* F2F Agenda

John Boyer: Please send suggested topics or time suggestions to the list.

* IRC Minutes


* Meeting Ends