Forms Working Group Teleconference -- 18 Apr 2012

<trackbot> Date: 18 April 2012

<Steven_> Chair: Steven

<scribe> scribe:nick

<scribe> scribenick:nvdbleek

Supporting AVTs in bind and model attributes

<Steven> http://lists.w3.org/Archives/Public/public-forms/2012Apr/0024.html

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].

Acknowledgments

<Steven> http://lists.w3.org/Archives/Public/public-forms/2012Apr/0011.html

Steven: What about past members
... 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].

Several updates to XPath Expressions Module

<Steven> http://lists.w3.org/Archives/Public/public-forms/2012Apr/0013.html

nvdbleek: xf:eval-in-context(), 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> http://www.w3.org/MarkUp/Forms/wiki/XPath_Expressions_Module#The_matches.28.29_Function

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> http://www.w3.org/MarkUp/Forms/wiki/XPath_Expressions_Module#The_XForms_Function_Library

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 note
... 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

<Steven> +1

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 optional features
... 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].

Definition of "dependent" and "reference" in Proposed Erratum 14, XForms

<Steven> 2.0, XPath Expression Module

<Steven> http://lists.w3.org/Archives/Public/public-forms/2012Apr/0016.html

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.

<ebruchez> +1

<Steven> +1

Steven: sounds good

<alain> +1

<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].

Type information

<Steven> http://lists.w3.org/Archives/Public/public-forms/2012Apr/0026.html

ebruchez: I haven't investigated it yet
... 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...

Made xpath error information available as context information for

<Steven> xforms-compute-exception and xforms-binding-exception

<Steven> http://lists.w3.org/Archives/Public/public-forms/2012Apr/0028.html

<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

Serializing XML declaration

<Steven> http://lists.w3.org/Archives/Public/public-forms/2012Apr/0030.html

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].

- DRAFT -

Forms Working Group Teleconference

18 Apr 2012

Attendees

Contents