<trackbot> Date: 06 June 2012

<scribe> scribe: John_Boyer

script/@type="text/xforms" support in XSLTForms

<Steven> http://lists.w3.org/Archives/Public/public-xformsusers/2012May/0000.html

Alain: You can embed xforms in script tags
... Useful in CMS

Steven: So you still need the script to XSLTForms in the head, but then you can put the XForms in the body

Alain: no processing instruction needed
... script not even necessary in the head
... DRUPAL for example allows you to define scripts to be added to the head

Nick: Why can you just put it in the normal DOM?

Alain: Normal DOM doesn't look at what's in the script tag when type is not javascript
... so you can have namespaces
... The model can be inside the script element
... Currently only one script element with this type is allowed, but I could use subforms to allow multiple

xforms:load/xforms:resource/@value

<Steven> http://lists.w3.org/Archives/Public/www-forms/2012Jun/0000.html

Steven: This question is from a group that has implemented XForms 1.1
... I'm going to spend a day with them soon and hope they will join the group

<ebruchez> http://www.w3.org/TR/xforms11/#action-load

John: I think the answer is yes
... ref that does attach to a node produces empty string, and that would be closest behavior to value producing empty string

Nick: In empty string case, it probably loads itself

Erik: If you have a base URL
... The problem is that you have two different behaviors if there is some kind of expression problem
... It seems to be undesirable for the value attribute to use "an empty string if the xpath evaluation fails"

<Steven> <load ref="foo"/> <load.<resource value="foo"/></load>

John: Well, xpath eval fail is different from xpath not resolving. In the fail case, the ref will produce an binding exception.

<Steven> s/load\./load>/

<ebruchez> http://www.w3.org/TR/xforms11/#ui-output

John: I think "if the xpath fails" probably actually means "if the xpath doesn't find any nodes" because a real failure as in failing to parse the expression should produce an exception in value attr

Erik: It should be the same as the output element

Steven: It's worse for load than for output because it loads a page you don't intend, whereas for output, it only shows an empty string

John: Still, an actual error in the xpath itself that makes the eval fail should produce an exception, so spec seems wrong there (on load and output)
... But failing to bind to a node is not an xpath failure. It just behaves differently on load/@ref versus load/resource/@value

Erik: We use the sentence 14 times in 1.1, so we should be careful about changing from permission to exception

Steven: Why is there an implementation specific means of conveying the error?

John: Some processors at the time would hand over control of resolving the URL to the browser, and others were client-side code that had a better response that stayed within the current form

Erik: Looks like most occurrences of the value attr fail silently, so it doesn't look unintentional
... In some cases we are specific about there being an error
... If you look in the header element, failing to evaluate a header seems like it should stop the submission

John: Why would any of these cases be different? They are form author errors, so it seems they should always produce an error rather than fail silently.

Steven: Does anyone support failing silently?
... If so, we would need to resolve that in order to reply to this.

John: Well, that actually isn't what the email is asking.
... He's pointing out that a ref doesn't resolve *to a node* then action has no effect. If same expression is put into value attr, then empty string results

Steven: Isn't it incorrect to have the inconsistency?

John: ref behaves the same across all actions, doing the equivalent of being non-relevant
... value can produce an empty string whether coercing an empty nodeset, or whether it finds a node that is empty
... output has the same behavior, ref not resolving to a node hides the whole output including its label. value producing empty nodeset still show the output, iincluding its label and the empty string

<scribe> ACTION: John to respond to email to indicate behavior is correct (different behavior of ref vs. value on load) according to above minutes [recorded in http://www.w3.org/2012/06/06-forms-minutes.html#action01]

<trackbot> Created ACTION-1905 - Respond to email to indicate behavior is correct (different behavior of ref vs. value on load) according to above minutes [on John Boyer - due 2012-06-13].

FPWD of XForms 2.0

Steven: I'll meet up with you Nick tomorrow

Erik: What is blocker?

Nick: The references section of the expression module is busted

<nvdbleek> http://www.w3.org/MarkUp/Forms/wiki/XForms_2.0#Common_Attributes

John: Also we need to resolve on promoting model to the common attributes
... promoting model to common needs to come along with restricting its value to current model on bind and header plus changing wording of rebuild recalculate revalidate refresh

Erik: It seems better to allow the model element to appear and restrict its value, rather than the recent revision which says some elements forbid this attribute of the Common attribute group

John: http://www.w3.org/MarkUp/Forms/wiki/XForms_2.0#The_rebuild_Element

Erik: rebuild recalculate revalidate refresh should say that it applies to model of current context

RESOLUTION: Promote model attribute to common attribute group

Note: further discussion needed on details of above resolution next week.

thanks Steven

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)

FAILED: s/load\./load>/
Succeeded: s/like all/like most/
Found Scribe: John_Boyer
Inferring ScribeNick: John_Boyer
Default Present: nvdbleek, Steven, ebruchez, John_Boyer
Present: nvdbleek Steven ebruchez John_Boyer Alain
Regrets: Philip
Agenda: http://lists.w3.org/Archives/Public/public-forms/2012Jun/0001
Found Date: 06 Jun 2012
Guessing minutes URL: http://www.w3.org/2012/06/06-forms-minutes.html
People with action items: john

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