See also: IRC log
<trackbot> Date: 06 June 2012
<scribe> scribe: John_Boyer
Alain: You can embed xforms in
... 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
... 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
... 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
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
John: I think the answer is
... 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
... 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.
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
... 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
... 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].
Steven: I'll meet up with you Nick tomorrow
Erik: What is blocker?
Nick: The references section of the expression module is busted
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
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.
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.[End of scribe.perl diagnostic output]