Forms Working Group Teleconference -- 13 Feb 2013

<trackbot> Date: 13 February 2013

Next week

Steven won't be here; we need a chair.

Nick: I can do it.

ACTION-1931: Propose text for @accept on upload

http://lists.w3.org/Archives/Public/public-forms/2013Feb/0019.html

Nick: I'd rather that new text not be added directly to the live spec, but to separate articles before we add them
... I don't think we had consensus yet, so it shouldn't be in the spec.

Erik: I think we can roll back the spec.

Nick: And if we accept this, we also need to update the schema

Steven: We don't have enough people here to make a decision about this
... we ought to take it out until we have approved it.

Erik: We should maybe do it on the mailing list.

Nick: I think the new name is better, but the old name has been there right from the beginning.

Erik: But it is an inconsistency that we have the same name for two things.
... so there is an improvement.
... do we already have an @accept?

Nick: No

Erik: I like more consistency, so am inclined to be in favour; and it is not a deep change.

Nick: You are willing to update your implementation?

Erik: Sure
... What are the implications for the implementers?

Nick: We definitely need to test it, and we need two implementations.

<ebruchez> "list of MIME types for file upload"

Erik: HTML4 has @accept on forms, but that is different, but it has it on the input element

<ebruchez> http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.4

<ebruchez> http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#file-upload-state-(type=file)

<ebruchez> image/*

http://www.w3.org/TR/REC-html40/interact/forms.html#adef-accept

<ebruchez> http://www.w3schools.com/tags/att_input_accept.asp

Erik: Not every browser supports it.
... but presumably in the future there will be more.
... So this is my vote for doing this.

Uli: Shall I revert the spec?

Nick: No, let's leave it in, and see if Alain will support it.

ACTION-1922 - Add examples of the use of variables to the XForms 2.0

http://lists.w3.org/Archives/Public/public-forms/2013Feb/0017.html

Steven: Any outstanding questions?

Erik: No. Everything is taken care of.

Nick: Shouldn't the inline example be on one line?

Erik: I did that already.

Uli: Can you use variables in binding expressions?

Erik: Yes. Why not?
... Variables are updated during refresh
... order is guaranteed.
... Do you see a problem?

Uli: You could interpret it in two different ways.

Erik: A var holds the value of the expression.

[echo makes it hard to hear]

scribe: no conversion

<nvdbleek> The value of a variable is any sequence of nodes and/or atomic values, as defined in XPath Data Model [http://www.w3.org/MarkUp/Forms/wiki/XForms_2.0#ref-xpath-data-model].

Erik: There's nothing transformative about the var element

Uli: OK

Target attribute on submission and load element

http://lists.w3.org/Archives/Public/public-forms/2013Feb/0009.html

Erik: This started with an email by MSM who had a use case for this. target="new", and we hadn't decided to use "new", but follow HTML for what was allowed.
... the HTML spec has a table with the acceptable values
... so we don't need to reinvent it
... question is whether it should go on the load action
... load is a small version of a submission. It cannot control @show
... so I am leaning to support it in both places.
... HTML syntax is horrible, but that is for historical reasons

Nick: Why do we need @show then?

Erik: It is duplicate, so we don't need it.

Steven: @show comes from xlink, and I guess at XForms 1.0 we were trying to adopt their syntax.

Erik: Using HTML syntax makes out syntax more understandable for people coming to XForms for the first time

Nick: There are some values in HTML that don't apply to XForms, like _parent and _top

Erik: Why do you say _parent doesn't apply?
... it may or may not apply, even in HTML

Nick: You are proposing to use the same keywords as HTML?

Erik: I would want to do as little work as possible. So XForms should refer to the host language.
... whatever makes sense for the host language
... even show="new" may not make sense for some host langauges

Steven: Want to try doing some spec text?

Erik: OK

<scribe> ACTION: Erik to suggest text spec for target keywords referring to host language. [recorded in http://www.w3.org/2013/02/13-forms-minutes.html#action01]

<trackbot> Created ACTION-1932 - Suggest text spec for target keywords referring to host language. [on Erik Bruchez - due 2013-02-20].

MIP functions

http://lists.w3.org/Archives/Public/public-forms/2013Jan/0025.html

Uli: Erik already responded that he agrees, and it should be an action item for him.

Nick: Are they available at the same time during recalculation?

Erik: I think valid() is the hard one
... we have to be careful
... but the current spec text is rather conservative
... but the other functions could be used in more places. I will have to see

<scribe> ACTION: Erik to suggest spec text for MIP functions [recorded in http://www.w3.org/2013/02/13-forms-minutes.html#action02]

<trackbot> Created ACTION-1933 - Suggest spec text for MIP functions [on Erik Bruchez - due 2013-02-20].

The function Element

http://lists.w3.org/Archives/Public/public-forms/2013Jan/0028.html

Nick: I think it is a useful feature.
... maybe it could be made simpler

Erik: XForms is tightly integrated with XPath
... ... a big missing feature is functions. See XQuery and XSLT for instance.
... which is painful
... we need functions
... there is a real use case

Nick: We support the feature as well.
... Abstracting business logic; makes code easier and more understandable

Erik: Every programming language has functions.

Uli: I see the use case, but aren't we reinventing the wheel?

Nick: It is based on how others did it, and making it as similar as possible.

Uli: Aren't we losing our declarative approach?

Nick: I don't see that.

Erik: Functions are in XPath, but not exposed there. It is exposed in XQuery and XSLT.
... we decided to reuse XSLT function element
... we talked with Michael Kaye about it
... he suggested not copying XSLT exactly
... and since we don't implement XSLT in XForms, there is much we don;t need.
... So that's how the current syntax emerged. And it is rather simple.

Uli: I see that. I'm not convinced it should be in core, because it is a work around XPath deficiencies

Nick: Well, functions could be written in javascript as well

Steven: There is a need for an abstraction to encapsulate a bit of code with a name, so that you don't need to repeat it everywhere.

Uli: I think it should be in the expressions spec, not the XForms spec

Erik: I have no problem with the function element in core

Steven: We have no consensus to remove this feature

Uli: I understand.

- DRAFT -

Forms Working Group Teleconference

13 Feb 2013

Attendees

Contents