- From: Erik Bruchez <ebruchez@orbeon.com>
- Date: Thu, 29 May 2008 13:43:00 +0200
- To: "public-forms (new)" <public-forms@w3.org>
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.
-Erik
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, x-port.net
> * Agendahttp://lists.w3.org/Archives/Public/public-forms/2008May/0067.html
> 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:
>
> http://lists.w3.org/Archives/Public/public-forms/2008May/0054.html
>
> IRC supplement: http://www.w3.org/2008/05/21-forms-minutes.html
>
> * Rich Web Application Backplane
> John Boyer: Another call this Friday.
>
> * Action Item Listhttp://lists.w3.org/Archives/Public/public-forms/2008May/0063.html
> 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)http://www.w3.org/2002/09/wbs/32219/formsftf200806/
> 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 dependencieshttp://lists.w3.org/Archives/Public/public-forms/2008Apr/0100.html
> 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
> andhttp://lists.w3.org/Archives/Public/public-forms/2008Apr/0100.html
>
> * UIInlinehttp://lists.w3.org/Archives/Public/public-forms/2008May/0047.html
> 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 neededhttp://lists.w3.org/Archives/Public/public-forms/2008May/0062.html
> 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.
>
> * Announcementshttp://lists.w3.org/Archives/Public/public-forms/2008May/0043.html
> 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 Forcehttp://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.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 Minuteshttp://www.w3.org/2008/05/28-forms-minutes.html*
> Meeting Ends
--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/
Received on Thursday, 29 May 2008 11:43:46 UTC