See also: IRC log
<trackbot> Date: 13 June 2012
<scribe> scribe: John_Boyer
Steven: CMS company, very
enthusiastic about XForms
... They have an XForms implementation with some very nice
features
... a whole workplace, an xform rendition, validation area,
etc.
... They have a design tool. They can also can convert an HTML
form to XForms with copy-paste ease
... They want to be a member of the working group
... working on OK from their management
... They also want to do a workshop on XForms business and/or
government
John: Thanks Steven, that is a great and motivating report, Thanks for visiting them
<Steven> http://lists.w3.org/Archives/Public/public-forms/2012May/0034.html
Steven: can we resolve this namepace change?
RESOLUTION: Functions go into XForms (2003) namespace
<Steven> http://lists.w3.org/Archives/Public/public-forms/2012Jun/0003.html
<nvdbleek> http://www.w3.org/MarkUp/Forms/wiki/XForms_2.0#The_header_Element
<Steven> Nick: Is it allowed on insert as well?
<Steven> ... you did it for header, var and bind?
<Steven> John: Yes
<Steven> Nick: Why not on actions?
<Steven> John: We're trying to ensure data doesn't travel between models
<Steven> ... a var makes the variable available in the model, but if a var can point to other vars, it can bring values from other models
<Steven> ... we should discuss this
<Steven> John: There's a non-normative note about actions
Nick: Why isn't model allowed on var?
<Steven> Erik: What about dispatch?
<Steven> Nick: dispatch could mix models
<Steven> John: But there's no cross-model data-dependency
John_Boyer: var would then consume data from one model and pull it into another model
<Steven> ... didn't we already have that problem?
John_Boyer: in the past we've had this rule of thumb to avoid creating cross-model data dependencies
<nvdbleek> http://www.w3.org/TR/xforms11/#action-dispatch
John_Boyer: When model is used on an insert, delete or setvalue, it resets the context of the whole action
<Steven> John_Boyer: We may need to create more restrictions to handle those
John_Boyer: It sounds pretty safe that children of dispatch could bind to different models because the result is an event
Nick: Not sure why there is a limitation on switching models with var
John_Boyer: I could see removing the restriction on both var and header; the real issue was crossing models on the bind element due to cross-model dependencies
Erik: Would actions within the model have any restrictions? I think they don't
RESOLUTION: Remove restriction on model from header and var, leave restriction to current model on bind element
<scribe> ACTION: Nick to Remove restriction on model from header and var, leave restriction to current model on bind element [recorded in http://www.w3.org/2012/06/13-forms-minutes.html#action01]
<trackbot> Created ACTION-1906 - Remove restriction on model from header and var, leave restriction to current model on bind element [on Nick Van Den Bleeken - due 2012-06-20].
John_Boyer: Erik I agree no
restrictions on model attributes of actions in a model, neither
before nor now
... Only other thing I did was change description of rebuild,
recalculate, revalidate, refresh and reset, which used to have
model as special attributes
<Steven> http://lists.w3.org/Archives/Public/public-forms/2012Jun/0006.html
Steven: This is now done
http://lists.w3.org/Archives/Public/public-forms/2012Jun/0006.html
Nick: yes I think we agreed to that, but there is a lot of work in the spec to do that
Erik: My concern is that I don't yet know what to implement, and all that needs to be specified
John_Boyer: Do we need Alain to give us a description of what got implemented for load/@show=embed?
Nick: input from community group?
Alain: Yes we implemented, and the implementation is compatible with betterForm. BetterForm has some extension functions that XSLTForms doesn't implement, but the baseline is there.
Erik: It would help to have an email with a few bullet points to describe implementation issues like what to do with IDs, events, models, etc.
<scribe> ACTION: Alain to send email to working group with further implementation details for load/@show=embed that describes how the implementation works and how it handles issues like IDs, event propagation, embedded models, etc. [recorded in http://www.w3.org/2012/06/13-forms-minutes.html#action02]
<trackbot> Created ACTION-1907 - Send email to working group with further implementation details for load/@show=embed that describes how the implementation works and how it handles issues like IDs, event propagation, embedded models, etc. [on Alain Couthures - due 2012-06-20].
Alain: it is very useful to have load/@show=embed for subforms
Steven: Any other spec review issues?
Nick: There was an override
issue, but it could be covered after FPWD
... I added an override feature for XPath functions, like what
is in XSLT
Erik: You can implement a
function in XSLT to make sure an implementation is there, and
override lets you decide whether to let a native implementation
override or override the native implemenation with the one in
the XSLT
... Not sure the override feature is critical for XForms, but
it is in XSLT
... Could ask Michael Kay what he thinks about the value of the
override feature
... We have to weigh value versus implementation difficulty
John_Boyer: Is it a security
problem to let a document arriving and overriding functions in
the native implementation?
... I mean, when the XForm is running in the browser.
Nick: XSLT has the same
problem
... When running in a browser
<nvdbleek> Nick: An implementation may have a custom function that isn't behaving as the form expects, in those cases it is desirable to override the function
Erik: an implementation won't let you crush a native implementation. It's a local change
John_Boyer: I don't understand; does the override feature specify that it only makes a local change?
<nvdbleek> Nick: Another use case is that you specify the function in both script and native xforms and don't wan't to override the script version if the processor supports the script language
Erik: No, an overriding function in an xform could override a function provided by the xforms processor
<nvdbleek> but only extension functions, not functions in the XForms namespace nor in the xpath function namespace
John_Boyer: It seems off that an xforms processor defined function could be overridden
Erik: We could say that override only applies to extension functions, not those in xforms
Steven: Does it make sense to ask Michael Kay?
John_Boyer: Yes, although he
probably doesn't do much with digitally signing XSLT.
... makes sense to ask Michael about the value to XSLT of the
override
Steven: need a resolution about FPWD. Any objections?
All: no
RESOLUTION: Publish FPWD of XForms 2.0 and XPath Expression module
hmm, what's taking zakim so long?
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/* Topic/Topic/ Succeeded: s/teh/the/ Succeeded: s/TH/Th/ Succeeded: s/made/may/ Succeeded: s/Topic: Spec review// Succeeded: s/down/done/ Found Scribe: John_Boyer Inferring ScribeNick: John_Boyer Default Present: +44.782.483.aaaa, +1.323.425.aabb, nvdbleek, +1.650.919.aacc, ebruchez, Steven, Philip, alain Present: +44.782.483.aaaa +1.323.425.aabb nvdbleek +1.650.919.aacc ebruchez Steven Philip alain John_Boyer Regrets: Kurt Agenda: http://lists.w3.org/Archives/Public/public-forms/2012Jun/0008 Found Date: 13 Jun 2012 Guessing minutes URL: http://www.w3.org/2012/06/13-forms-minutes.html People with action items: alain nick WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]