See also: IRC log
<klotz> scribe: ebruchez
<klotz> scribenick: ebruchez
<klotz> http://lists.w3.org/Archives/Public/public-forms/2010May/0000.html
Leigh: No news, no rumors.
Nothing to report.
<klotz> scribe: klotz
<scribe> scribenick: klotz
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.
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]