W3C Forms teleconference April 28, 2010

* Present

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

* Agenda


* Previous Minutes

* Upcoming telecons

Steven Pemberton: I cannot chair the next two weeks.

* Rechartering


Steven Pemberton: The charter wasn't discussed last week, but I did respond that we replied to the comments.

* Action Item Review


Steven Pemberton: Any reports?

* Lyons

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.

* xslt() extension function proposal from Claudius Teodorescu

This thread http://lists.w3.org/Archives/Public/public-forms/2010Apr/0027.html This thread http://lists.w3.org/Archives/Public/www-forms/2010Apr/0018.html Original Message http://lists.w3.org/Archives/Public/www-forms/2010Apr/0008.html Nick's wiki page: http://www.w3.org/MarkUp/Forms/wiki/Transform Talk page: http://www.w3.org/MarkUp/Forms/wiki/Talk:Transform

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.

* Next Meeting

Steven Pemberton: I won't be here for two weeks.
Philip Fennell: I won't be here next week.

* IRC Minutes


* Meeting Ends