W3C

- DRAFT -

SV_MEETING_TITLE

12 May 2010

See also: IRC log

Attendees

Present
Nick_van_den_Bleeken, Leigh_Klotz, John_Boyer, +0782483aaaa, pfennell, [IBM], wiecha, +1.650.515.aabb, ebruchez
Regrets
Chair
SV_MEETING_CHAIR
Scribe
ebruchez, klotz

Contents


<klotz> scribe: ebruchez

<klotz> scribenick: ebruchez

<klotz> http://lists.w3.org/Archives/Public/public-forms/2010May/0000.html

Rechartering

Leigh: No news, no rumors.

Action Item Review

Nothing to report.

<klotz> scribe: klotz

<scribe> scribenick: klotz

xslt function

nick: the doc function has the same problem in xslt
... and id

john: it's hard to get to that with id() and now we've got to get to it because this is a bigger use case.
... so it will not meet expectations easily unless we do a lot of work

nick: it's more unusual to change id attributes

leigh: the element with the id may move around

nick: or be inserted or deleted

john: delete and insert tend to rebuild

nick: maybe we can say that you have to rebuild for the xslt function, but i'm not big supporter

leigh: that's more like the xslt action and then saying it's like insert.

nick: not entirely.

john: it would effectively do an insert and a rebuild

erik: we're talking about 1.x action or function. a requirement for xslt may be too heavy. on the other hand if we make it optional, is it worth it?

leigh: i think we're discussing two things: xslt action vs function, and also pushing on the xquery/xpath2.0 framework issues for xforms 1.2. i'd like this to be an extension module so that implementations are compatible with each other in their extensions, and this proposal comes from an implementor.

erik: one big issue is nodes that aren't in an instance: doc(), node creation, and xslt function. is there anything else in this that's problematic?

leigh: that's one issue; the other is whether about whether we put in features that might trip up people in some way or other, such as input bound to xslt(), or to something where a trivial change might make a big change in speed.

nick: not all xslt transformations are expensive. some may be milliseconds

john: our design environment reads markup patterns; if you have an xslt function it's powerful and might be too much. it's harder to find them.
... it's like assembly language. a transformation with specific use cases, prior to submission and an action, might be easier to find. it's easier to parse the xml than the xpath string.

erik: there is no doubt that xslt() is complex; it's a superset of xpath. otoh, if it's an optional module, you might not have to handle it at all.

john: philip said that in an email, keep it as an action as optional content, and the function version as well.

leigh: i'd like to have xslt action module for 1.2 and then leave the function open for more experimentation; when we get to the point of solving the doc() function issues we may be more motivated to solve it.
... i'd like to solidify the xslt action for 1.2 as a module, and then leave open xslt() as a function because we'll need to solve the problems with doc() as well

nick: we still have the same problems

erik: we can add this to the list of xpath 2.0 support issues, with the doc() function

leigh: we will have to get consensus on the function for doc() first.

nick: i'd like not to have a function and an action

leigh: I'd like to do incremental spec development in the wiki with the text for both, and let interested parties work on it. the xpath 2.0 set of issues will need to be solved before the function.

john: xpath 2.0 isn't tailored for xforms; same with technical disconnects in xml schema. it does 99% of what we want but there is 1% problem, like the doc() function.

leigh: we can certainly outlaw doc() via uri resolution rules, but that's a big step

erik: we only use xpath 2.0; we don't use (as far as I remember) the doc function. certainly not in bindings.
... we still have the issue of what happens with nodes that are not in instances. do we disallow doc() or disallow doc() in binding? In the end, it's just a decision to make.
... we have flexibility to say that, as leigh was saying. i hope the number of issues is small, less than a handful.

john: it's a technical fit, not an in-practice issue. it may be 99.999% in practice because they don't use the odd features.
... we still have to explain the edge cases.
... some fraction of 1,000,000 users will use it.

erik: it's unavoidable as things grow; the complexity isn't reduced, as in xpath 1.0 to 2.0.
... the justification is that you can do so much more. xpath 2.0 is a richer expression language.

john: i see the fear in the eyes of the QE engineers when one talks about increased flexibility.

erik: the flip side is that you have trouble with xpath 1.0 and multiple instances and are easier xpath 2.0

nick: we switched to 2.0 as well because a lot of things are easier.

john: some differences would be good to list, for a test suite for conformance.
... those then become the sales pitch for xpath 2.0, if youi list the solutions
... then you get test suite tests
... by communicating what problems people solve, and interop testing, with the primary use cases.
... the qa fear is that obscure, messy secondary use cases are now primary.

nick: do you see use cases for doc() right now; erik has reported not seeing it in the wild.
... you can use submission.

leigh: the only case I've seen with xquery and doc() is where query does fetches and iteration
... xforms doesn't have the loop construct that

john: it does have it; use @while and send and insert

nick: it's a lot of work to set up

<ebruchez> we were supposed to have an @iterate attribute on actions too, which somehow didn't get into XForms 1.1

leigh: iteration is the draw that makes you want to use doc() in xpath2 or xquery

nick: also replace.

erik: that's a good point; xpath 2.0 has a function library that's great in comparison to xpath 1.0.

nick: i also use sequences; you can iterate, reverse, intersect.

leigh: are the problematic, little-used features of xpath 2.0 that we should take a hard look it?
... is it just the doc function?

erik: i can't think of anything major right now?

<pfennell> Hello, can anyone here me?

nick: we should open up for sequences; it's some work

erik: an xpath 2.0 expr can return a sequence containing a string, attribute, text node, etc. more often is an expression returning a sequence of string. so can xforms repeat over a sequence? we support it.

leigh: that's useful. i'm looking for things that aren't useful: i want to find the low-hanging rotten fruit

pfennell: unparsed-entity() gives you text
... or is that in xslt?

leigh: maybe that's xslt

erik: there's a similar function collection() like doc()

nick: there are some native implementation functions that aren't in the instance but are providing data
... so we could say it's like an anonymous instance containing those nodes.

john: that would be good but then we'd have to have the schedule for updates. the issue the functions raise is what happens when the resources change? we have a dirty corner with id() and now().
... in xpath 1.0.
... we've decided that it's up to implementations to decide when to do that.

leigh: xslt caches during the transformation; http includes many cache directives. forever isn't a good answer for a form because it might be the only form; consider a kiosk

nick: we could say rebuild is when the cache can be revisited

john: xslt() function operates over live instance data. the doc() function references something that we don't know about volatility

nick: we need to do the work, maybe not now. just dependency engine tweaks.

<wiecha> +1

<John_Boyer> +1

leigh: xpath 2.0 is useful. the xslt() function might be useful. let's consider them together.

<John_Boyer> above +1's are about what Leigh just said

leigh: now, do we do xslt action now or is it unnecesary work? the +1 are about this

nick: I'm neutral

philip: I agree we should write up the xslt action. i agree that the issue of functions is tied t xpath to do separtely.

leigh: who wants to write it up?

<scribe> ACTION: leigh klotz to write up xslt action in xforms 1.2 wiki [recorded in http://www.w3.org/2010/05/12-forms-minutes.html#action01]

<trackbot> Created ACTION-618 - Klotz to write up xslt action in xforms 1.2 wiki [on Leigh Klotz, Jr. - due 2010-05-19].

leigh: nick, can you a place in the wiki to put the xslt() function?

nick: there's already a wiki page i created.

leigh: ok, i'll linjk it in.

Summary of Action Items

[NEW] ACTION: leigh klotz to write up xslt action in xforms 1.2 wiki [recorded in http://www.w3.org/2010/05/12-forms-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/05/12 16:05:21 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/id/id()/
Succeeded: s/doc()./doc() as well/
Succeeded: s/agree to write up/agree we should write up/
Found Scribe: ebruchez
Found ScribeNick: ebruchez
Found Scribe: klotz
Inferring ScribeNick: klotz
Found ScribeNick: klotz
Scribes: ebruchez, klotz
ScribeNicks: ebruchez, klotz
Default Present: Nick_van_den_Bleeken, Leigh_Klotz, John_Boyer, +0782483aaaa, pfennell, [IBM], wiecha, +1.650.515.aabb, ebruchez
Present: Nick_van_den_Bleeken Leigh_Klotz John_Boyer +0782483aaaa pfennell [IBM] wiecha +1.650.515.aabb ebruchez

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 12 May 2010
Guessing minutes URL: http://www.w3.org/2010/05/12-forms-minutes.html
People with action items: klotz leigh

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]