See also: IRC log
<trackbot> Date: 18 April 2012
<Steven_> Chair: Steven
nvdbleek: Do we want to support AVTs in bind and model attributes?
John_Boyer: I think we agreed previously to just call those out as binding exceptions for now.
nvdbleek: Fine for me
<scribe> ACTION: nick AVTs in bind and model attributes should not support AVTs [recorded in http://www.w3.org/2012/04/18-forms-minutes.html#action01]
<trackbot> Created ACTION-1892 - AVTs in bind and model attributes should not support AVTs [on Nick Van Den Bleeken - due 2012-04-25].
Steven: What about past
... List everybody who worked on this version and take previous from previous spec
John_Boyer: Alain and philip aren't listed
<scribe> ACTION: nick we will update the Acknowledgments list in both specs [recorded in http://www.w3.org/2012/04/18-forms-minutes.html#action02]
<trackbot> Created ACTION-1893 - We will update the Acknowledgments list in both specs [on Nick Van Den Bleeken - due 2012-04-25].
xf:replace() and xf:matches() pre-date the decision to target
XPath 2.0 for XForms 2.0. And you don't need those functions if
you have an XPath 2.0 engine.
... We have three possibilities:
1) Add those functions to XForms 2.0 like you have done
2) Don't add those functions to XForms 2.0 because you don't need them in XPath 2.0
3) Create a separate section were we group all the functions that are no longer needed if you have an XPath 2.0 engine, but are there for 'backwards compatibility'.
John_Boyer: The expression model
support XPath 1.0
... eval-in-context() is for XPath 1.0 compatibility
ebruchez: does an XForms engine that uses an xpath 2.0 engine also needs to implement xf:matches and xf:replace
John_Boyer: An XForms implementer can just forward the functions to the xpath versions
nvdbleek: We could add matches and replace to the default namespace to the default function namespace
ebruchez: in xforms 1.1 you can use is-card-number()
in XForms 2.0 this becomes xf:is-card-number() if xpath version is 2.0 in xpath 1.0 they are still in the default namespace
nvdbleek: An implementation may choose to make these additional function also available in the http://www.w3.org/TR/xpath20/#dt-def-fn-nsXP when the XPath version on the model is not 1.0 if he has a good reason for it (e.g.: Backwards compatibility).
ebruchez: Depending on the
implementation you may need to prefix functions if you switch
to xpath 2.0
... I propose: For backwards compatibility an implementation may make these additional function also available in the http://www.w3.org/TR/xpath20/#dt-def-fn-nsXP when the XPath version on the model is not 1.0
John_Boyer: We should take it
outside of a note
... We should change this to should be in default namespace
nvdbleek: we are taking a big step back when we say the 'should' be in the default namespace because we don't know what functions would collide in the future.
John_Boyer: We should resolve what happens with the clashes
nvdbleek: when XPath 2.0 is run in XPath 1.0 compatibility mode the functions are in the default namespace
John_Boyer: Take it out of
... We want to deprecate in the future, what about clashes
nvdbleek: with clashes we could choose the use the standard XPath functions
ebruchez: in case of clash take standard XPath functions
nvdbleek: I would like it to be a may
John_Boyer: must is too strong, may is too weak
ebruchez: some people don't like
... I'm concerned to current implementations that already support XPath 2.0
John_Boyer: The problem only occurs when you are switching implementations and they interprete the may differntly
<scribe> ACTION: nick to move text about backwards compatibility of functions out of note, make it may and deprecated [recorded in http://www.w3.org/2012/04/18-forms-minutes.html#action03]
<trackbot> Created ACTION-1894 - Move text about backwards compatibility of functions out of note, make it may and deprecated [on Nick Van Den Bleeken - due 2012-04-25].
<Steven> 2.0, XPath Expression Module
John_Boyer: We had a lengthy
discussion about this in the past
... I added the text to expression module so it isn't lost
... In the past we discussed to loosen the definition of reference to let all expressions work without the need of rebuild
... I was raising the issue the the term reference was used and that the definition was to lax in the calculation algorithm, causing it to create to easy a circular reference
... basically I tried to fix the problem for compute expressions, and not solve the complete problem with the reference definition
Steven: You made the changes,
what do we do with them
... leave them?
... everybody ok with this?
ebruchez: I'm re-reading it
John_Boyer: [explains the changes he made]
ebruchez: can you explain briefly explain why you only depend child nodes and not parent node
John_Boyer: when you have a node with attributes and child content, and the were doing calculations for the attributes and content in separate calculates, in the previous version this resulted in a circular dependency, now this no longer results in a circular dependency
ebruchez: what if an expression depends on attributes and text contents of a node
John_Boyer: maybe the re-write isn't good enough...
ebruchez: we did some experiments
using projections in Saxon
... it uses paths for what you are referencing
<John_Boyer> How about something more like "A computed expression references an instance node and uses the character content of that instance node..."
ebruchez: if you have b you can depend on the existence of node b or on the atomization of the node n (text content), this resulted in two different dependencies in the projection
John_Boyer: that is exactly what the original e-mail stated
ebruchez: should we maybe specify the diference between traversing a node a posed to using the text content
<John_Boyer> If a computed expression references an instance node and uses its character content (rather than just referencing for navigation), then the computed expression is dependent on that instance node.
Steven: sounds good
<scribe> ACTION: John to update computation dependencies 'f a computed expression references an instance node and uses its character content (rather than just referencing for navigation), then the computed expression is dependent on that instance node.' [recorded in http://www.w3.org/2012/04/18-forms-minutes.html#action04]
<trackbot> Created ACTION-1895 - Update computation dependencies 'f a computed expression references an instance node and uses its character content (rather than just referencing for navigation), then the computed expression is dependent on that instance node.' [on John Boyer - due 2012-04-25].
ebruchez: I haven't investigated
... pulling types in, changes the way expressions work, for example when a node is of type boolean it is no longer treated as a string but a boolean
... in XSLT when a schema is attached to the data expressions also behave differently because the types of the nodes are known
... The idea was to use the type information provided by binds, schema and xsi:type in the xpath engine
... so if shipped is a boolean node it is treated as a boolean in an expression
... in XForms we have to take into account what happens when the lexical value isn't conferment to its type (e.g.: xs:date) what should happen to that node (in XForms the instance contains invalid values)
... An option is to return a typed value when it is a valid value and an untyped value when it is invalid
nvdbleek: We have to look to real use-cases to see what the impact is when changing from untyped to typed values
ebruchez: it is strange that you need to repeat the type information in your expressions by casting your nodes
<alain> I have been disconnected and now it says that "the conference is restricted"... so I'm just on IRC now...
<Steven> xforms-compute-exception and xforms-binding-exception
<scribe> ACTION: Erik to send a e-mail to Michael Kay about providing type information to the nodes in instances [recorded in http://www.w3.org/2012/04/18-forms-minutes.html#action05]
<trackbot> Created ACTION-1896 - Send a e-mail to Michael Kay about providing type information to the nodes in instances [on Erik Bruchez - due 2012-04-25].
nvdbleek: I agree
John_Boyer: I responded that the format should be a space separated list of qnames specifying how serialization should happen
<scribe> ACTION: John to update text of serialize() and parse() that format is a space separated list of qnames [recorded in http://www.w3.org/2012/04/18-forms-minutes.html#action06]
<trackbot> Created ACTION-1897 - Update text of serialize() and parse() that format is a space separated list of qnames [on John Boyer - due 2012-04-25].
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/Chair: Steven/Chair: Steve/ Succeeded: s/Chair: Steve/Chair: Steven/g Succeeded: s/q mqy/a may/ Succeeded: s/string/strong/ Succeeded: s/to /too / Succeeded: s/to /too / Succeeded: s/copute/compute/ Succeeded: s/exress/express/ Found Scribe: nick Found ScribeNick: nvdbleek Default Present: Steven, Nick, alain, John_Boyer, ebruchez Present: Steven Nick alain John_Boyer ebruchez Agenda: http://lists.w3.org/Archives/Public/public-forms/2012Apr/0034.html Found Date: 18 Apr 2012 Guessing minutes URL: http://www.w3.org/2012/04/18-forms-minutes.html People with action items: erik john nick WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]