W3C

- DRAFT -

XForms Users Community Group Teleconference

11 Apr 2018

Agenda

Attendees

Present
Erik, Philip, Steven
Regrets
Alain
Chair
Steven
Scribe
Steven

Contents


Viewing Data with XForms

https://lists.w3.org/Archives/Public/public-xformsusers/2018Apr/0016

Steven: Please take a look

Philip: We don't have a method to sort on repeat do we?

Steven: No.

Philip: In Orbeon?

Erik: We have a sort function, but not as part of <repeat/>

Steven: That would be a good thing to present in a future article.
... where does your sort function come from Erik?

Erik: I need to check; I think it's an extension function.

Steven: Might be worth considering adding sort to the XForms functions.

function/@override

https://lists.w3.org/Archives/Public/public-xformsusers/2018Apr/0018

Steven: Done

Common attributes

https://lists.w3.org/Archives/Public/public-xformsusers/2018Apr/0017

Steven: Also done. Please check that it looks OK.

ACTION-2165: Forward the root element proposal to saxonica

https://lists.w3.org/Archives/Public/public-xformsusers/2018Mar/0037

https://lists.w3.org/Archives/Public/public-xformsusers/2018Mar/0028

Steven: Saxonica were OK with it.

Erik: No real strong feelings about it. The objections were regarding the style and title attributes.
... that's OK. I can live with it. I don't require it; if it works for others, then that's fine.

<scribe> ACTION: Steven to add root element to spec

<trackbot> Created ACTION-2168 - Add root element to spec [on Steven Pemberton - due 2018-04-18].

ACTION-2166: Unify output/label/help/hint/alert

https://lists.w3.org/Archives/Public/public-xformsusers/2018Mar/0038

https://lists.w3.org/Archives/Public/public-xformsusers/2018Apr/0019.html

Steven: I'm assuming everyone is OK about unifying the attributes.
... Erik, you said you didn't think linking on <help/> was necessary, and I agree.

https://lists.w3.org/Archives/Public/public-xformsusers/2018Apr/0019.html

Steven: the second point is that all elements have content, except <output/>
... so do we want to take the unification that far, or leave <output> as an empty element?

Philip: Why not use host-language facilities?

Steven: I use XForms elements as much as possible.
... but the point is, if we're unifying the elements, why not just go all the way.

Philip: Agree.

Erik: Hint and so on allow output within the content; would we allow that in output too? Allow nested outputs in output?
... for instance label has as content "(PCDATA|(UI Content))*", where UI Content is <output/> but implementations may extend it.

Steven: Yes. I'd like time to think about that.
... reraise it next week.

xforms-next/-previous

https://lists.w3.org/Archives/Public/public-xformsusers/2018Apr/0006

Steven: Looking at this table:

https://www.w3.org/community/xformsusers/wiki/XForms_2.0#Events

Steven: Looking at interaction events, the ones with equivalent actions, maybe they all ought to be actions rather than events; especially as we've deprecated some of them already.
... my feeling is that originally we gave events two roles, actions and notifications, but in fact notifications are the useful ones, and the others ought to be actions.

Erik: I agree.

Steven: Do we change or leave as is?

Erik: Anecdotally, I've never used next and previous events.

Steven: There are real-world usages

Erik: Not sure if those are good examples.

Steven: I agree.

Erik: Ideally it should be with an action.

Steven: Agree; Philip?

Philip: Yes.

<scribe> ACTION: Steven to add actions for nonj-notification interaction events

<trackbot> Created ACTION-2169 - Add actions for nonj-notification interaction events [on Steven Pemberton - due 2018-04-18].

@class on <repeat>

https://lists.w3.org/Archives/Public/public-xformsusers/2018Apr/0008

Steven: Erik, do you support @class on <repeat/>

Erik: Yes, I believe so...
... it translates by putting the class on the iterations.
... because we don't generate an enclosure for the repeats.
... I'd be inclined to accept the definition of an enclosing group.
... in some cases, it might cause troubles.
... the class on an enclosing element will be OK.
... should we be proscriptive about it?

Steven: I would prefer it that way.

<scribe> ACTION: Steven to suggest spec change for class on repeat.

<trackbot> Created ACTION-2170 - Suggest spec change for class on repeat. [on Steven Pemberton - due 2018-04-18].

submission request- and response-mediatype

[Alain]

Steven: Postpone to next week

AOB

Steven: I'm keynoting at Balisage this year.

[ADJOURN]

Summary of Action Items

[NEW] ACTION: Steven to add actions for nonj-notification interaction events
[NEW] ACTION: Steven to add root element to spec
[NEW] ACTION: Steven to suggest spec change for class on repeat.
 

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/04/11 13:42:21 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/I've/I've /
Succeeded: s/good think/good thing/
Succeeded: s/unigying/unifying/
Succeeded: s/orbeon/Orbeon/
Present: Erik Philip Steven
Regrets: Alain
No ScribeNick specified.  Guessing ScribeNick: Steven
Inferring Scribes: Steven
Agenda: https://lists.w3.org/Archives/Public/public-xformsusers/2018Apr/0020
Found Date: 11 Apr 2018
People with action items: steven

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)


[End of scribe.perl diagnostic output]