See also: IRC log
<trackbot> Date: 06 February 2013
<scribe> Scribe: Steven
http://lists.w3.org/Archives/Public/public-forms/2013Jan/0019.html
Steven: The last remark last week was from Uli "We need to talk about relevance"
Uli: About show and hide events
<unl> http://lists.w3.org/Archives/Public/public-forms/2013Jan/0021.html
Uli: Point 2, suggested behaviour
- close the dialog if it becomes non-relevant (we can't do much else anyway)
- don't re-open if it becomes relevant (idea: non-relevant controls lose
state information)
Uli: Is this consistent with other controls?
Nick: More or less
Uli: I'm not sure that our
controls lose state when they go from relevance to
non-relevance and back
... it may be implementation-dependent
... does it get recomputed?
Erik: I'm not sure we ever
finished that discussion
... compare switch-case which has changed state, what happens
then? This would be similar.
... maybe if the spec says, we can do the same.
... In any case it seems odd that it should pop back into
life.
Nick: Agree
Uli: OK
Steven: So agreed.
http://lists.w3.org/Archives/Public/public-forms/2013Jan/0022.html
<unl> http://www.w3.org/MarkUp/Forms/wiki/Bind_function
Uli: We had some wiki text. It's not hard to do
Nick: There are some
problems.
... it implicitly creates dependencies
Uli: The dependency engine has to be aware of the bind function?
Nick: The text of the dependency
engine says it only looks at arguments
... that would be hard to get right
... it would change the core spec, not only the functions
spec
Erik: There are many places where
you could use bind()
... it has many uses
... if it is to hard to revise the dependency text, we can say
it is undefined
Uli: The instance() function surely has the same sort of problems
Nick: Except it returns the root node, which doesn't change
Erik: and a structural change
gives a rebuild
... but I agree about the comparison between build and
instance
... and there are problems with allowing it on bind refs.
Steven: Does anyone implement this yet?
Erik: We do, but we ignore the dependency aspects
Steven: So it has no effect on the dependencies?
Nick: We use it, but you have to be careful using it, it effects the ordering of binds
a/effects/affects/
Steven: So the ordering of binds becomes important, and not interoperable?
Erik: We should ban it on bind@ref
Nick: Also dangerous for a recalculate, since ti won't be automaitcally recalculated.
Erik: right
<ebruchez> <bind ref="foo" calculate="bind('other-bind')"/>
Uli: You could statically analyse xpath expressions
Erik: The spec has never required that, that would be really new
<ebruchez> <bind ref="bind(contact('other', id))">
<nvdbleek> <bind ref="foo" calculate="bind(../foo)"/>
Nick: That is a counter example to static analysis
Uli: So disallow it on bind expressions
Nick: Use vars?
Erik: If we prohibit it, then implementations can't even try to fix it.
<ebruchez> "If the function is used in a model binding expressionXF the XForms Processor should terminate processing after dispatching the event xforms-binding-exception to the model. If the function is used in a computed expressionXF the XForms Processor should terminate processing after dispatching the event xforms-compute-exception to the model."
Nick: We should watch out for
adding new features to the last-call spec
... we need two interoperable implementations, and be
comfortable with the definition
<ebruchez> (the above is about the valid() function)
Erik: We could use similar text
to that from valid(), see above
... Note the "should" there
... sometimes the spec is too strict I find
Steven: value="bind('constant', xpath)"
<unl> value="concat(bind('a'), bind('b'))"
Uli: You also want to use it deep in an expression
<ebruchez> calculate="foo + bind(''bar)"
Steven: I think we need to work on this feature more before we add it to the spec. It is now too late for the LC spec
Uli: I don't think bind() is to hard too specify.
Steven: We have a time constraint.
http://lists.w3.org/Archives/Public/public-forms/2013Jan/0024.html
<unl> http://lists.w3.org/Archives/Public/public-forms/2013Feb/0003.html
Uli: These things are two different things; I propose we change the attribute name to "accept"
Nick: I made an error. I should not have deprecated the mediatype element.
Erik: We need to fix that mistake.
<scribe> ACTION: Nick to fix the upload/mediatype deprecation error [recorded in http://www.w3.org/2013/02/06-forms-minutes.html#action01]
<trackbot> Created ACTION-1929 - Fix the upload/mediatype deprecation error [on Nick Van Den Bleeken - due 2013-02-13].
Uli: They should also have
different names
... since they are different things.
... It would be nice to reduce some markup bloat
Erik: I would like to use
attributes instead of nested elements
... I'm not against moving to attributes.
Uli: There are more places where
we could do that
... we should do it at all places where possible
Erik: I thought I sent out a proposal for this last year
<ebruchez> http://lists.w3.org/Archives/Public/public-forms/2012Feb/0030.html
Uli: I shall reread the spec for all places where we could do this.
<scribe> ACTION: Uli to propose all places where child elements can be replaced with AVT attributes [recorded in http://www.w3.org/2013/02/06-forms-minutes.html#action02]
<trackbot> Error finding 'Uli'. You can review and register nicknames at <https://www.w3.org/2005/06/tracker/xforms/users>.
<scribe> ACTION: Ulrich to propose all places where child elements can be replaced with AVT attributes [recorded in http://www.w3.org/2013/02/06-forms-minutes.html#action03]
<trackbot> Created ACTION-1930 - Propose all places where child elements can be replaced with AVT attributes [on Ulrich Nicolas Lissé - due 2013-02-13].
Uli: What about accept attribute on upload?
<scribe> ACTION: Uli to propose text for @accept on upload [recorded in http://www.w3.org/2013/02/06-forms-minutes.html#action04]
<trackbot> Error finding 'Uli'. You can review and register nicknames at <https://www.w3.org/2005/06/tracker/xforms/users>.
tracknot, help
trackbot, help
<trackbot> Please see <http://www.w3.org/2005/06/tracker/irc> for help.
<scribe> ACTION: Ulrich to propose text for @accept on upload [recorded in http://www.w3.org/2013/02/06-forms-minutes.html#action05]
<trackbot> Created ACTION-1931 - Propose text for @accept on upload [on Ulrich Nicolas Lissé - due 2013-02-13].
[ADJOURN]
This is scribe.perl Revision: 1.137 of Date: 2012/09/20 20:19:01 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/TH/Th/ Succeeded: s/TH/Th/ Succeeded: s/bond/bind/ Succeeded: s/SO/So/ Succeeded: s/ti/it/ Succeeded: s/TH/Th/ Succeeded: s/ us / use / Succeeded: s/ to / too / Succeeded: s/atti/attri/ Found Scribe: Steven Inferring ScribeNick: Steven Default Present: nvdbleek, Steven, ebruchez, unl, +1.443.837.aaaa, Kurt Present: nvdbleek Steven ebruchez unl +1.443.837.aaaa Kurt Regrets: Philip Agenda: http://lists.w3.org/Archives/Public/public-forms/2013Feb/0007 Found Date: 06 Feb 2013 Guessing minutes URL: http://www.w3.org/2013/02/06-forms-minutes.html People with action items: nick uli ulrich[End of scribe.perl diagnostic output]