Erik Bruchez, Orbeon
John Boyer, IBM
Leigh Klotz, Xerox (minutes)
Philip Fennell, MarkLogic
Steven Pemberton CWI/W3C (chair)
Uli Lissé, DreamLabs
counterexample.Steven Pemberton: I've received a
note about XBL2 which we'll need to discuss.
Erik Bruchez: It seems there is
serious activity going on with something similar to XBL; it's a
JavaScript. One of the presenters is a CSS editor, Tab Atkins, for
now works for Google. One of the topics is Web Components, but he
didn't get to talk about it. Another guy who works for Google this
week blogged about shadow DOM. I have a feeling that these guys,
are working on something.
Uli Lissé: http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/
Uli Lissé: http://annevankesteren.nl/2011/01/xbl
Erik Bruchez: So I would be interested
in developing on something that someone else develops, but I don't
think we have enough bandwidth to develop. Maybe we can leverage
the enthusiasm and excitement and make it or an extension
compatible with XForms components.
Steven Pemberton: So you think it
would be really good to have a spec but we shouldn't do it.
Erik Bruchez: We would need enough
motivated people and we don't have the bandwidth.
John Boyer: I agree; it makes sense,
but it's a bandwidth.
Leigh Klotz: I think the shadow DOM
stuff we can use like HTC, and it's incredibly important for us and
others to be able to use. But it won't have namespaces or other
stuff we need to implement XForms components, so we still need to
do something for components.
Erik Bruchez: The developers are
Mozilla and all are 100% aware of XBL. They want to take what's
been done with XBL2 and simplifying it and re-evaluating use cases,
and get something that works with HTML5. There's momentum that
seems to be happening. I don't think we can take XBL2 in parallel.
What I can see as possible is making sure that what they are doing
will work in an XHTML context or with namespaces, or if that's not
happening, then saying with XForms, we need extra things
(namespace-awareness). But I don't know what will be
developed.
Leigh Klotz: We still need to do
components and I don't think the HTML5 thing is going to produce
something we can use to combine xf:input and xf:action and so on
into widgets. So we could use Orbeon's XBL2 subset or not, but we
need something.
Erik Bruchez: I'm not sure that's
true. The use cases they have at http://wiki.whatwg.org/wiki/Component_Model_Use_Cases
shows encapsulated widgets, sliders, tab views, etc. All those use
cases might not be covered, but they are the same use cases we have
in XForms. It's the same concepts in the XBL2 spec. I don't think
that it's a given that what they come up with will be less useful
than XBL2. XBL2 is abandoned.
Leigh Klotz: Using the same "WebBL"
would make it difficult to have a single vocabulary for shadow DOM
in the browser and also allow XForms namespace to markup.
Erik Bruchez: I think we should watch
and see what they're doing. If it's essentially XBL2 but with some
essential additions, I'd rather use that as a base than XBL2. If as
an XForms implementor in JavaScript in the browser, if that model
can be leveraged right of the way that's great, but I don't know.
If it's not possible, I'd rather have a dialect of that rather than
a dialect of something different. On the server you can implement
XBL2, but you can also implements the web components thing; it
should be about the same. The concern here is not to build on
something that is known to be abandoned. Maybe what they're doing
is very close, but we have to look at what's different.
Leigh Klotz: What if they remove
namespace support and we can't bind to XForms elements?
Erik Bruchez: There's binding and
styling; CSS supports namespaces. If they keep the XBL2 approach,
as a template language, then CSS would support namespaces. If they
don't, then we add that back in. It's an incremental change. We'd
have to say we need incremental changes on top. The alternative
would be to say that just because we need namespace support we need
to define something completely different.
Leigh Klotz: Did you take a look at
the spec that had namespace support removed/
Erik Bruchez: No.
Steven Pemberton: There may come a
time where we need to decide. My answer should then be that we
value a specification for interoperability, but the current group
wouldn't have the bandwith, but they would be happy to have use
cases covered.
Leigh Klotz: Rather than divergent
specs as I suggested, we should follow Erik's lead and ask for
extensions to the new WebBL that support out use cases, such as
namespaces, and we can support the use case development. So if we
can get that done, then we don't need a separate spec.
Steven Pemberton: I think we've
discussed the issue to my satisfaction.
John Boyer: We talked about this
last week. The form has a simple data model with a few nodes and a
couple of binds. If you run this in a processor that implements the
XForms 1.1 definition of node-test references (and it doesn't get
the leaf-node value), you notice the calculated values get out of
sync in a fairly ridiculous way. Yes can be less than No, and you
get Prevail. It always seems to be one step behind. The reason for
this is that the element poll_result has attributes, and the way
the referencing system works with the node-test rule, bind to an
attribute creates a reference to the parent element. That's
inappropriate because the bind/@calculate doesn't refer to the
poll_result element itself, only the attributes. If you follow the
absolute letter of the spec, you wind up with a computational
circular reference. It's clear to the reader that there is no
circular reference, but by our definition of reference, there is.
So it seems like a proof that the definition must be wrong.
John Boyer: When our implementation
finds a circular reference, it doesn't do a compute exception; it
does the best job it can, running the computs in order. It will at
least calculate a result. As a result, we're seeing a wrong or out
of sync answer rather than simply blowing up. Either result could
be reasonable expected. The prior definition of reference for model
bindings under XForms 1.0 (which was somewhat unclear about
"dynamic") is not only must you match a node test, but the XPath
has to grab the string value of the node. That fixes this problem:
If you have an XPath expression, it's not just the node test that
matches, but you also have to grab the string value of the node
during the XPath evaluation; that's what counts as referring.
Matching a node test...the second bind in this model has a
calculate with choose(../@yes_count ...). The ../@yes_count grabs
the string value of @yes_count, but that also counts as a reference
on the parent node as well. That's what creates false
references.
Leigh Klotz: Is this peculiar to
attributes, or does the bad result generalize to children
elements?
John Boyer: The peculiarity is that
the calculate always refers to an endpoint and a calculate points
to a leaf node. In order to generalize to problems other than
attributes you'd have to be calculating a mixed-content thing. So
If poll_result had yes_count and no_count then if poll_result
itself were also used in the first bind to point to
poll_result.
Leigh Klotz: Maybe we can focus on the
attribute and leaf-node issue and make fewer changes that might
produce problems.
John Boyer: It's the element
poll_result is a complex type with simple content and we're saying
that our reference mechanism breaks the correctness of calculating
the simple content while also calculating the value of an
attribute.
Erik Bruchez: I agree there's no
circular reference. It's the text value of the elements. It's
pretty straightforward.
Leigh Klotz: Is this about attributes
and how calculate leaf nodes are determined?
John Boyer: No, it's about all model
bind nodesets.
Leigh Klotz: Don't you have dynamic
problems with rebuilds in the model, like <bind
nodeset="a/b/c">?
John Boyer: No, you have to rebuild
anyway when the number of "b" changes. If you do
a/b[pred]/c then the c will change based on the
predicate, but nothing in reference of node test fixes that anyway.
We optimized an edge case of not having to do rebuilds as often,
but in the process we broke complex type with simple content. One
case got optimized at the cost of correctness in the other.
Leigh Klotz: What if we just said that
the parent elements of attributes are not taken into account?
John Boyer: It would solve that but
not the mixed-content case. I don't agree that that's circular
reference. It's OK to reference the value of the first text node of
a poll result in a complex type with two child elements. I would
imagine it's a more marginal edge case, but it does exist and is
another instance of incorrectness. It seems the better approach in
the long-term is to be less precise abotu what referencing means
and recognize an interop problem, and somehow relax the definition.
For the short term, there may be rebuilds you need to do (per
implementation) but in the long term, we should fix the fact that
we need rebuilds.
Erik Bruchez: This example is
interesting. With a completely different algorithm (static
analysis), I could solve that problem and determine the order. Last
week we said that determining the order would be hard with static
analysis. But here we have a case where that would be possible. It
would be a partial order in general, but here it is perfectly
determinable. By static analysis I mean we can look at the
expressions and determine the path touched in a hypothetical
instance; you could look at it purely as a performance gain. I like
the idea to relax the spec enough that we could choose to implement
something in a completely different way yet still be compliant yet
still do most of what the original spec wanted to do.
Steven Pemberton: [irc] +1 to
that
John Boyer: I'm very concerned about
that approach; I want to fix our algorithm so that it would
generate the same order as the static analysis; the algorithm
shouldn't be less smart. It would be better to have more power at
runtime than you do in the designer. It's an orthogonal point. You
don't implement the order thing, but all I want is to make that do
as well as the static analysis.
Erik Bruchez: There are some things
you can't do as easily as with static analysis without hooks into
the XForms engine. As an example, for short-circuiting you have to
run everything in the engine, but it's easier to do statically.
Saxon XPath 2.0 already has the feature to analyze the expression
and it returns the expression tree you walk statically and figure
out the paths touched.
John Boyer: We're still talking about
implementation choices. That same static analyze could be run at
runtime. When we turn off short-circuiting, we run the static
analyzer at runtime to find out what nodes are touched. I do think
that the only place that runs into trouble is that
a/b[pred]/c, would you say all a/b/c are
being touched?
Erik Bruchez: Yes.
John Boyer: So you basically ignore
predicates. That's another implementation issue.
Erik Bruchez: It's quite that simple.
In XPath 2.0 you have quite complicated predicates. You have less
of that issue if, for a given node you can determine the paths that
the node will depend on. So it's a set of dependencies that might
be at runtime bigger than the actual set of dependencies. Maybe I
only depend on a/b[4]/c[5], but we don't know the
shape of the instance so we don't know that statically. It's not
identical to what you're doing.
John Boyer: You're describing a
different way of analyzing the XPath, which we could do at design
time or at runtime. You're using a means other than evaluation to
calculate the dependency. Our opinions can converge there; I think
we both agree that the spec is too specific on saying how the
references are determined, which is orthogonal to how an XForms
engine can determine the order to run the binds in. The higher
level statement is that we want the system at runtime to figure out
the order; if there's some means better than evaluation of the
XPath, then great, but in an ideal world we wouldn't have a
rebuild. In an ideal world, if the document order of the binds is
"incorrect" the processor would just work that out.
Erik Bruchez: Right
John Boyer: Short term, we have a lot
of implementations of XForms 1.1 that don't do what the spec says;
Orbeon does one way for order, because of problems with the
definition. We do another way in the model because of problems with
the definition. I think that the genesis of the definition was
because we were trying to unify definition of references in
model-binding and UI-binding. I think the discussion started with
repeat/input wanting numerous references for so we could allow UI
binding dynamic predicates and the UI would know how to update. So
that's a requirement and the spec is pretty good about not saying
more about how to implement that. Implementors want some help
described, so we tried to bend, I think incorrectly, the definition
of referencing around the UI binding and it broke the model because
the model still has rebuild in it.
Steven Pemberton: We need to conclude
for today. It sounds like future work for getting rid of rebuild is
valuable. It sounds like we need implementation advice along with
the definition. The definition should be freestanding. What we do
need is some erratum for this which we don't have time for today.
If the erratum is loosening up the definition that sounds good to
me. John, do you feel like you could find a definition for
that?
John Boyer: I could.
Action 2011-01-19.1: John Boyer to propose erratum for loosening the definition for model nodeset references. http://www.w3.org/2011/01/19-forms-minutes.html#action01 NOT IN TRACKBOT YET