Dan McCreary, Dan McCreary Associates
John Boyer, IBM
Steven Pemberton, CWI (chair)
Leigh Klotz, Xerox (chair)
Kurt Cagle, XMLToday
Philip Fennel, MarkLogic
Erik Bruchez, Orbeon
Nick van den Bleeken, Inventive Designers
Steven Pemberton: Deadline is very
soon. Web storage is not a large document. Perhaps Alain would like
to read it.
Steven Pemberton: Web Workers is
thread-like with message passing.
Kurt Cagle: Let me take a look at that
one.
ACTION-1824 - Kurt Cagle to review for next week's deadline: http://www.w3.org/TR/2011/WD-workers-20110901/
Steven Pemberton: The deadline is September 27. I'll ask Alain to review Storage.
John Boyer: I'm writing a blog
entry. You can introduce bias into survey responses by giving the
choices in the same order. Randomizing choices is a standard
feature. We could do this server side, but it might be possible to
do this with an appearance attribute. It would be a good idea to
turn this into a space-separated list of named token.
Steven Pemberton: Isn't there an
argument for a function instead?
John Boyer: The most declarative thing
would be select1 choices being presentational. However appearance
is a presentational hint.
Leigh Klotz: The function would let
you save the choice order so you could sign it.
John Boyer: A good segue. I wrote a
function to generate a permutation using loop and if.
John Boyer: I wanted to have it done
in model-construct-done and have it go back to the choice where my
position was equal to some random permutation. The position()
function changes inside a predicate; I needed
context()/position().
Steven Pemberton: You create a list of
numbers for a list of each length.
John Boyer: Yes, for each different
list length. I had a difficult time without creating a secondary
list.
Leigh Klotz: There's already
fn:unordered but it's not really unordered.
Nick van: You can use
count(current()/preceeding-sibling::*) instead of position.
John Boyer: I want to choose the
permutation value according to the context position.
permutation/value[context-position()]
John Boyer: Once you're inside the
outer predicate everything inside the bracket...
Nick van:
count(current()/preceding-sibling::choice)
John Boyer: Thanks, I'll give that a
try.
Nick van: It is not elegant but is a
trick I use often.
John Boyer: If you get the current
choice node and count its preceeding siblings that lets you figure
out which permutation you want.
Leigh Klotz: Tom Schnetlage told us
this, I think, back in the XForms 1.0 requirements days. He also
told us that users needed to be able to unset any value they set,
which we can do.
John Boyer: We also need the sort
function. Anybody, it would be nice if @appearance would be a
space-separated list.
Leigh Klotz: I can't find anything in
the minutes back to 2001 about appearance, other than it started
out as selectUI and turned into appearance. I thought we discussed
space separated and decided not to but I can't find it.
John Boyer: We did in CR for XForms
1.1.
Leigh Klotz: Why not use the function?
Otherwise it's hidden data like repeat-index and case.
Steven Pemberton: We may want other
things to use the function as well. I don't have any objection to
the appearance being a space-separated list, but I don't think it's
the rigth place.
Nick van: In XSLT sorting is not
trivial.
John Boyer: So space-separated list
and keywords. We added a compare function but we didn't add the
capabilities of XPath 2.0.
Leigh Klotz: So why not just add a
permute function that takes a random number.
John Boyer: And produces a list.
Leigh Klotz: Or produces a
nodeset.
John Boyer: That worries me about
ordered nodeset.
Nick van: A nodeset is always in
document order. A sequence isn't.
John Boyer: Most implementations can't
do it.
Leigh Klotz: There is an unordered
function in XPath 2.
Nick van: That returns a
sequence.
John Boyer: That's OK. I wanted an
easy way. Nick has given me a hint to how to use it as a
lens.
Nick van: Not being able to do a
sequence of nodes in XPath 1 and adding sequences in 2 is a great
addition. It opens up a lot of cool stuff.
Erik Bruchez: I haven't been
tracking that specifically.
Steven Pemberton: Can you summarize
this?
Erik Bruchez: It's a non-declarative,
Javascript API way of doing XBL, mostly with involvement from
people at Google. They have a wiki with proposals at
https://github.com/dglazkov/component-model
Erik Bruchez: Instead of a separate
language such as XBL2, you would load components as HTML DOM and
call on any element in the browser to set the shadow DOM. For
exampl, load the video player component and where you have the
video player element (div with a specific class, for example) and
attach the behavior to that loaded shadow DOM. They have the XBL
features necessary for components: events don't go through the
boundary; you can include page contents (i.e., the tab content
element). They seem to be aggressively working on it.
Erik Bruchez: I downloaded Chromium
but haven't had time to look at it to see if they have any shadow
DOM. There has been some use of the Shadow DOM in Google Chrome for
input controls, video controls, to make components.
Erik Bruchez: Here is the link:
http://wiki.whatwg.org/wiki/Component_Model
Steven Pemberton: What are the
conclusions?
Erik Bruchez: In the future, we might
have client-side implementations like XSLTForms done using this:
textarea, repeat, etc could be done using this instead of XSLT. I
could use a Shadow DOM implementation for each construct. The
Firefox implementation of XForms was similar. And that's what it's
meant to do.
Leigh Klotz: I think it's very
powerful and I hope they bring it out.
Erik Bruchez: There are some
high-profile people (Alex Russell who works on Dojo at Google) who
are vocal about wanting it to happen.
Leigh Klotz: Are we ready to write
this up?
Leigh Klotz: I sent a patch to
XSLTForms about @iterate but didn't know how it interacted with @if
and @while.
Erik Bruchez: I have Action-1812 to do
this. The @context (which we support everywhere) is done first,
then @iterate changes the context. I think we apply @if and that
modifies the context for each iteration, then @while.
Leigh Klotz: My simple implementation
just did one of @iterate, @if, or @while.
John Boyer: What if you wanted @if
outside the @iterate? For internal use you can nest
action/@if.
Erik Bruchez: Code that mixes them is
difficult to read; perhaps it is just to be considered bad
practice.
Steven Pemberton: Do we exclude @if if
you use @while now?
Erik Bruchez: It's a little easier;
the XPath evaluation context for @if and @while are the same so
they don't influence the other. If you have an @if you must
evaluate the @if, and similarly for @while.
John Boyer: It is almost certainly
true that we evaluate the @if first. If you evaluate the @while
first then you can get into an infinite loop.
Erik Bruchez: The content of the
action is in the context of the iteration; at each iteration the
context is the current item, just as with repeat and xsl:for-each.
So you need to change the context inside. The question then is if
you have an @if does it apply to that iterated child context or the
outer context, before changing to the current iteration.
Leigh Klotz: Do have any use cases
that involve @iterate and @if or @while?
Erik Bruchez: Perhaps. @iterate and
@while are more likely exclusive, but @if and @iterate could be
used together with @if first.
Steven Pemberton: Then we would have
to say that.
John Boyer: If an action has both
@while and @if we say both must be true before iteratively
executing the contained action. So @if has to be evaluated after
@if.
Leigh Klotz: I guess the previous loop
of @while could have side effects.
Nick van: We dropped @iterate because
of side-effects involving deleted items.
Leigh Klotz: We decided that wasn't a
new problem: action could have multiple delete children
anyway.
Erik Bruchez: Yes, it's a not a new
problem; there is an execution context.
John Boyer: ... infinite loop
...
Erik Bruchez: We have two cases in our
implementation: no @iterate, and @iterate. If no @iterate, we
iterate over one element. Then we check @if and break out of
everything. Then we check @while and if it's false we break out of
everything. So it's like an outer action with an @iterate and an
inner action with an @while.
Leigh Klotz: By "everything" do you
mean toplevel?
Erik Bruchez: No, only the current
iteration. It's exactly like an outer action with @iterate and an
inner action with @if or @while or both?
Leigh Klotz: Or we could just say that
we prohibit @iterate with @if|@while and say that if you want
nested @iterate with @if|@while inside then you go write
that.
Erik Bruchez: @iterate is more
functional. @while is more imperative. I would say you would use
one or the other but not both. I would say it's ok to say that you
can have either @iterate or @while, but I'm not sure about
@if.
Steven Pemberton: You can write this
anyway using nested elements. Or you can combine them and this is
how they work. We have to do one or the other. Erik, I'd like you
to propose one or the other on the mailing list and come to a
conclusion. From what Leigh says it may be easier just to do
@iterate alone.
Leigh Klotz: Implementation isn't hard
but I don't want to lead authors to think they can control behavior
by changing the order of attributes.
Steven Pemberton: Right. So Erik if
you can write this up for the mailing list we can discuss it next
week.
ACTION-1826 Erik Bruchez to propose @iterate combination with @while @if.