Erik Bruchez, Orbeon
Leigh Klotz, Xerox (minute)
Nick van den Bleeken, Inventive Designers
Philip Fennell, MarkLogic
Steven Pemberton, CWI/W3C (chair)
Charlie Wiecha, IBM
Uli Lissé, DreamLabs
Steven Pemberton: I cannot chair the next two weeks.
Steven Pemberton: The charter wasn't discussed last week, but I did respond that we replied to the comments.
Steven Pemberton: Any reports?
Steven Pemberton: Nothing yet to
report because of the W3C web conference.
Charlie Wiecha: Are we still waiting
on the 4-day confirmation?
Steven Pemberton: Yes. The
questionnaire closes this week.
Charlie Wiecha: I might be able to
offer some facilities.
Nick van: John's not here.
Philip Fennell: I share John's
concerns, but I don't know the details of his technical concerns.
It boils down to whether you might be able to use it in a calculate
on a binding, because there's no way of stopping someone from doing
that.
Nick van: We can disallow it in
certain places. The (unfinished) MIP functions would not be allowed
in certain places, to prevent circularity. So we would disallow it
in bind/@ref and not in calculate (until we have more
implementation experience), and repeat and UI control ref
attributes. Maybe later.
Philip Fennell: It sounds like it is
easier to define where it is allowed. Output?
Nick van: And actions, because it's
executed at a specific point.
Philip Fennell: Is this the xslt
function or should this be the action?
Steven Pemberton: There's no harm in
having both, is there?
Nick van: If we have the action, it
will be a combination of insert and the function. We'd have to
repeat all the insert attributes.
Philip Fennell: If we don't have the
action, do we then lose the ability to use conditionals?
Nick van: No, because an insert action
can be used in an action block. You can use insert/@ref="xslt"...
You cannot use an action in a function though. It's more general,
though.
Leigh Klotz: XSLT is functional unless
you break it with vendor-specific extension functions. So I think
it's useful to have as a function rather than shoe-horning it into
an imperative framework. I understand John's concern about not
leading people down an garden path of slowness, but it's not clear
that's the case yet.
Nick van: There's the example on the
wiki page of output mediatype="text/html".
Leigh Klotz: So Philip said maybe
output, setvalue and insert.
Nick van: We already the id
function.
Leigh Klotz: How about itemset/value
and itemset/label?
Nick van: If you don't re-evaluate on
every refresh and the XSLT stylesheet is compiled it could be
really fast.
Philip Fennell: In the wikipage
there was a serialize. Are we going to roll out serialize for
dynamic views?
Nick van: We already have dynamic
output.
Philip Fennell: I speak from
experience with Mozilla and JavaScript for serialization of
instances as text. It's quite a desirable use case.
Leigh Klotz: If you just want text
can't you use method=text in the XSLT?
Nick van: It's easier to output nodes
than a string.
Philip Fennell: That doesn't output
the elements.
Erik Bruchez: The serialization is in
a different specification from XSLT. It makes sense to have a
separate function for transformation and serialization. It depends
on whether it mostly produces XML trees, or whether it produces
other things. Whether we include that in a single function that
uses transformation output, or whether we allow the author to
specify the serialization externally depends on the use cases. I
believe the saxon:xslt function produces a tree and Saxon has a
serialization function; that gives you maximum flexibility.
Philip Fennell: In my scenario the
problem would go away if you bind an output to complex
content.
Nick van: I first wrote the example
with a comment saying that, but I decided that was a different
feature.
Erik Bruchez: If you have two
functions, you can handle both scenarios. With the function, you
can insert nodes in a tree and get a DOM manipulation toolkit.
Whether controls can handle complex-content is a separate case. So
you could structurally modify one of your instances. Then if you
want to output HTML with xf:output, you need to serialize the
result as a string. There's definitely a way to hook them together
to cover the use cases.
Steven Pemberton: Are we happy with
this? It sounds like we're converging on a solution where we use
the function, and may restrict where it can be used. Or we say you
can't do it but you'd better watch out.
Nick van: We should say it's
implementation-dependent. We did that with something.
Leigh Klotz: repeat and switch. But
what about @calculate? Is it structurally a problem or is it
because John thinks it is too slow?
Nick van: I'm not sure what the
concern is.
Leigh Klotz: Evan Lenz convinced me
that XSLT and XQuery are pretty much the same, and I already
believe XQuery and XPath 2.0 are pretty much the same. So I don't
see why we can't use calculate.
Erik Bruchez: Yes, in principle, but a
stylesheet could access external documents, for example. It's too
hard to analyze.
Leigh Klotz: If you give the xslt
function a small part of the instance can't we analyze it?
Nick van: We can say that external
URIs are stable over the lifetime of a form as they do.
Erik Bruchez: In XSLT it's the
lifetime of the transformation but we could say it's for the
lifetime of the form.
Nick van: It's possible in
Saxon.
Leigh Klotz: If you are doing it in a
browser, the browser's cache should take care of Cache-Control and
other HTTP features.
Nick van: We can say it's the whole
page lifetime.
Leigh Klotz: Imagine a kiosk that
always stays on the same page. That doesn't work.
Erik Bruchez: Imagine an xslt
transformation that takes only a URL; every occurrence always
fetches.
Nick van: It would fetch the same
URI.
Erik Bruchez: Yes. We do that in our
pipelines. If we fine dynamic document functions we do caching for
them.
Leigh Klotz: If you use XHR in modern
browsers it seems to respect HTTP cache just fine. XSLT says that
you can cache it for the duration of the XSLT and an HTTP cache
will determine.
Erik Bruchez: I think it's too much to
say in the spec that things have to be cached.
Leigh Klotz: I think that XSLT should
cache it if it wants to. If there's no way for the author to tell
then it's OK to cache and we don't need to specify cache
optimization behavior ourselves.
Erik Bruchez: Yes.
Leigh Klotz: So I think
bind/@calculate is ok.
Steven Pemberton: So is there anywhere
we don't want it?
Nick van: Bind, input control refs and
nodesets, because it's not in an instance and doesn't have
MIPs.
Erik Bruchez: I think you might use it
in bind/@id and no MIPs. I'm not 100% sure. It seems like we're
saying that bind/@ref and control/@ref are allowed to bind only to
instance nodes? We will have things that return subtrees and things
that never belong to an instance such as node creation and XPath
2.0 doc() function (and XPath doc functions). If we're going to
disallow controls and bind/@ref, we might want to take a step
back.
Leigh Klotz: That goes with my thesis
that XSLT and XPath aren't different.
Erik Bruchez: XSLT always returns a
copy; XPath and XQuery can return a selection from the input
node.
Leigh Klotz: Can't you return an XPath
result?
Nick van: No, you have to have at
least an XML node.
Erik Bruchez: We can ask implementors,
but I think XSLT is always doing a copy. But anyway, the scenario
is that once we introduce such tools into XForms, we have to handle
the nodes not in instances.
Leigh Klotz: So you're saying we
should look at our binding sites and decide which ones must be
bound to instance nodes? We already have the event context
function.
Erik Bruchez: XSLT is just one of the
situations where that can happen.
Leigh Klotz: Is there a case where you
want to bind input to one of these things?
Nick van: There are use cases, but our
lifecycle may not be well enough defined to handle it.
Erik Bruchez: It's definitely
something I can see how to handle easily; you have an expression
that returns non-instance nodes, and you can detect that
dynamically or statically. You can determine whether to re-evaluate
the expression. We use magic in XForms how controls update anyway:
we don't specify how and leave that to implementors.
Nick van: I can see if you write a
form in one processor and a refresh does the disabled/enabled and
the other does it only when the data it uses changes, and yet
another only does it when the touched data is changed.
Erik Bruchez: That shouldn't change,
at least once we finish the UI events. If we had an event sent the
node you're bound to changes. You'd get an event when you're newly
bound; even if you replace the node underneath you wouldn't get a
new node underneath.
Nick van: It's not
well-specified.
Erik Bruchez: I'm hoping the UI events
are well specified someday.
Leigh Klotz: If we have input/@ref
bound to xslt are we making an instance that's accessible only via
context nodes?
Nick van: If you re-run the
transformation the data is gone.
Erik Bruchez: XSLT doesn't say what
the result is. It's not a DOM. I suppose we could make readonly
DOM. It doesn't seem useful for input. For output, it could be more
useful.
Leigh Klotz: It seems like it makes
anonymous instance data accessible via context node, and you could
bind input and additionally other xslt calculations on the context
node. So it's internally consistent.
Nick van: If you do refresh a lot you
lose the values.
Leigh Klotz: So how about this, which
Erik hinted at: return MIP-readonly nodes. Then output is
unaffected (probably) and input will work, but you can't take it
very far (i.e. you can't change values or type anything in and then
lose it) so John won't get support calls (probably).
Nick van: So how do you do the
binding? bind/@ref?
Leigh Klotz: bind/@readonly would be
already set and bind/@calculate wouldn't work because it's already
essentially a calculated node. bind/@relevant might be useful, and
bind/@type certainly would be useful.
Nick van: So Maybe it's not a
problem.
Steven Pemberton: So let's end there.
Do we resolve something today or wait?
Nick van: I'd like to wait for
John.
Leigh Klotz: And I'm sure Teodoro and
Philip would like to send in some more comments based on their
implementation experience.
Steven Pemberton: I won't be here
for two weeks.
Philip Fennell: I won't be here next
week.