Re: Updated minutes for 2008-05-28

Thanks Leigh for the detailed minutes. Very useful for the absentees.

And thanks Steven for adding our announcement to the WG's home page. I  
will do a demo at the f2f.


On May 28, 2008, at 8:30 PM, Leigh L. Klotz, Jr. wrote:

> I forgot to include the previous-minutes link.
> W3C Forms teleconference May 28, 2008* PresentCharlie 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,
> * Agenda
> 	• Previous Minutes
> 	• Rich Web Application Backplane
> 	• Action Item List
> 	• Next FtF (June 9-12, Amsterdam)
> 	• Expression dependencies and dynamic dependencies
> 	• UIInline
> 	• Spec reviews needed
> 	• Announcements
> 	• Forms Task Force
> 	• XForms 1.1
> 	• F2F Agenda
> 	• IRC Minutes
> 	• Meeting Ends
> * Previous MinutesPrevious minutes:
> 	•
> 	• IRC supplement:
> * 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.
> 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:
> 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 
>  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 
>  and
> * 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: 
> 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 
>  and present straw set of comments for discussion and approval at F2F.
> Action 2008-05-28.4: Charlie Wiecha to review 
>  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.
> Leigh Klotz: So our comments better be brief.
> Action 2008-05-28.5: Leigh Klotz to review 
>  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? 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?
> 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 
> 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 
>  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.1Progress 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

Orbeon Forms - Web Forms for the Enterprise Done the Right Way

Received on Thursday, 29 May 2008 11:43:46 UTC