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
http://lists.w3.org/Archives/Public/public-forms/2008May/0054.html
John Boyer: Another call this Friday.
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.
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.
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
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.
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.
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.
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
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.
John Boyer: Please send suggested topics or time suggestions to the list.