IRC log of forms on 2013-03-20

Timestamps are in UTC.

14:59:26 [RRSAgent]
RRSAgent has joined #forms
14:59:26 [RRSAgent]
logging to http://www.w3.org/2013/03/20-forms-irc
14:59:28 [trackbot]
RRSAgent, make logs public
14:59:28 [Zakim]
Zakim has joined #forms
14:59:30 [trackbot]
Zakim, this will be IA_XForms
14:59:30 [Zakim]
ok, trackbot; I see IA_XForms()11:00AM scheduled to start in 1 minute
14:59:31 [trackbot]
Meeting: Forms Working Group Teleconference
14:59:31 [trackbot]
Date: 20 March 2013
14:59:48 [Steven]
Agenda: http://lists.w3.org/Archives/Public/public-forms/2013Mar/0014
14:59:56 [Steven]
Steven has changed the topic to: Agenda: http://lists.w3.org/Archives/Public/public-forms/2013Mar/0014
15:00:01 [Steven]
Chair: Steven
15:03:30 [Zakim]
IA_XForms()11:00AM has now started
15:03:36 [Zakim]
+??P32
15:03:43 [Steven]
zakim, I am ?
15:03:43 [Zakim]
+Steven; got it
15:04:14 [Zakim]
+[IPcaller]
15:04:30 [alain]
Zakim, I am [IPcaller]
15:04:30 [Zakim]
ok, alain, I now associate you with [IPcaller]
15:04:52 [ebruchez]
ebruchez has joined #forms
15:05:56 [Zakim]
+ebruchez
15:06:44 [nvdbleek]
nvdbleek has joined #forms
15:07:16 [nvdbleek]
zaki, code?
15:07:22 [nvdbleek]
zakim,code?
15:07:22 [Zakim]
the conference code is 93676 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), nvdbleek
15:07:51 [Zakim]
+nvdbleek
15:07:59 [pfennell]
pfennell has joined #forms
15:08:15 [nvdbleek]
zakim, who is here?
15:08:15 [Zakim]
On the phone I see Steven, [IPcaller], ebruchez, nvdbleek
15:08:16 [Zakim]
On IRC I see pfennell, nvdbleek, ebruchez, Zakim, RRSAgent, Steven, alain, windauer, trackbot
15:08:49 [windauer]
windauer has left #forms
15:09:14 [pfennell]
Joining the call in a minute.
15:09:27 [Steven]
We'll start when you get here
15:09:50 [Zakim]
+pfennell
15:11:02 [nvdbleek]
scribe: nick
15:11:08 [Steven]
Topic: Reminder - Call times back to normal next week
15:11:08 [Steven]
http://lists.w3.org/Archives/Public/public-forms/2013Mar/0000.html
15:11:26 [nvdbleek]
Topic: Orbeon Forms 4.0
15:11:26 [Steven]
Topic: Orbeon Forms 4.0
15:11:26 [Steven]
http://lists.w3.org/Archives/Public/public-forms/2013Mar/0008.html
15:11:26 [nvdbleek]
http://lists.w3.org/Archives/Public/public-forms/2013Mar/0008.html
15:12:02 [nvdbleek]
Steven: congratulations with the release
15:12:03 [Steven]
ACTION: Steven to add Orbeon announcement to home page
15:12:03 [trackbot]
Created ACTION-1938 - Add Orbeon announcement to home page [on Steven Pemberton - due 2013-03-27].
15:12:21 [nvdbleek]
Topic: [ACTION-1934] Completed (Update the XML and relax-ng schema (change
15:12:22 [nvdbleek]
mediatype to accept on upload))
15:12:22 [nvdbleek]
http://lists.w3.org/Archives/Public/public-forms/2013Mar/0013.html
15:13:02 [nvdbleek]
Steven: Erik you commented it
15:13:25 [nvdbleek]
ebruchez: I think there is an issue with XForms-20-Schema.xsd: you replaced the nested mediatype element with an accept element. But the mediatype element must stay, and an accept attribute must be added instead.
15:13:31 [nvdbleek]
ebruchez: If you see the diff
15:13:33 [ebruchez]
https://dvcs.w3.org/hg/xformsusers/rev/79a8870aa69c
15:14:04 [Steven]
reopen action-1934
15:14:05 [trackbot]
Re-opened ACTION-1934 Update the XML and relax-ng schema (change mediatype to accept on upload).
15:14:39 [nvdbleek]
Topic: textarea/@mediatype and Rich Text Editors
15:14:39 [nvdbleek]
http://lists.w3.org/Archives/Public/public-forms/2013Mar/0011.html
15:14:40 [nvdbleek]
http://lists.w3.org/Archives/Public/public-forms/2013Feb/0002.html
15:14:57 [nvdbleek]
Steven: Alain said that a media-type isn't enough
15:15:07 [nvdbleek]
alain: There are different kind of editors
15:15:26 [nvdbleek]
alain: They want to say which options they want
15:16:15 [nvdbleek]
Steven: I can see this is a valid thing to do, but I think we should only handle the general case for now (only specifying the type)
15:16:49 [nvdbleek]
alain: Users want different editors
15:17:48 [nvdbleek]
nvdbleek: On the last call we kind of agreed that it should be type based, similar to xs:data for a date control
15:18:37 [nvdbleek]
alain: In xsltforms there is a way to associate types with widgets
15:20:12 [nvdbleek]
nvdbleek: Currently there is no cross-implementation way to specify widgets/custom components, so I think there is no need in to map types to widgets for now
15:21:11 [nvdbleek]
ebruchez: On output we have media type to specify the 'renderer' to use, this is simpler then specifying it in the model with a data type for the form author
15:21:57 [nvdbleek]
Steven: There are two aspects to the consistency we have the datatypes on the one side (for input) and the media type attribute on output on the other side
15:23:22 [nvdbleek]
ebruchez: there is a convenience aspect on specifying it in the view. In the passed we were thinking of also allowing other things like readonly to also be specify able in the view
15:23:30 [ebruchez]
xforms:html
15:23:56 [nvdbleek]
ebruchez: If we want it to be data type driven we need to come up with a xs datatype
15:24:34 [nvdbleek]
Steven: in his email he said it as a restriction of a datatype
15:25:57 [nvdbleek]
ebruchez: to me it should be simple. If you have a datatype, then it should be specified in the spec (like xforms:email), but it will be a marker data type because we can't specify the rules to make it valid html
15:26:25 [nvdbleek]
Steven: We could also go for both, in the model and on the control
15:26:49 [nvdbleek]
alain: I like the the standard datatype for html
15:28:03 [nvdbleek]
alain: in XSLTForms you will still have the way to specify the widget to use by restricting xforms:html
15:28:21 [nvdbleek]
ebruchez: Would we require any validation on that datatype?
15:30:01 [nvdbleek]
Steven: if the validation differs between implementations then some implementations may submit html that other implementations not
15:30:17 [nvdbleek]
Steven: most widgets do a fragment not a whole document
15:31:03 [nvdbleek]
ebruchez: We could say that implementations aren't required to do any validation checking, but are they allowed to validate the content
15:31:29 [nvdbleek]
Steven: any string that you submit to a browser gets displayed
15:32:12 [nvdbleek]
Steven: So we shouldn't require that it is well-formed, ….
15:32:25 [nvdbleek]
Steven: We shouldn't require that it is validated
15:33:07 [nvdbleek]
ebruchez: it is very hard to validate if something is valid html
15:33:26 [ebruchez]
(it's hard to find a way to specify it)
15:33:29 [nvdbleek]
Steven: how does XSLTForms handle validation on html widgets?
15:33:47 [nvdbleek]
alain: Everything the widgets makes is valid html
15:34:15 [nvdbleek]
Steven: the xforms:html can't be invalid (all values are valid according to the xforms processor)
15:34:39 [nvdbleek]
Steven: The proposal is to add new data type, do we call it xforms:htmlfragment
15:36:34 [ebruchez]
xforms:xhtmlFragment
15:36:56 [ebruchez]
xforms:HTMLFragment
15:37:13 [nvdbleek]
s/xforms:htmlfragment/xforms:HTMLFragment/g
15:37:40 [nvdbleek]
Steven: no extra validation (any string is valid)
15:38:21 [nvdbleek]
Steven: The widget may guarantee to always generate valid HTML
15:38:31 [ebruchez]
s/xforms:xhtmlFragment/xforms:htmlFragment
15:40:19 [nvdbleek]
RESOLUTION: Add a new xforms data type xforms:HTMLFragment that will trigger a rich text editor
15:42:03 [nvdbleek]
nvdbleek: does it work for input or only textarea?
15:42:26 [nvdbleek]
ebruchez: input is single line input, text area is multiple lines
15:44:07 [nvdbleek]
ebruchez: but we have the use-case were we want on line with only bold, italic and links
15:44:34 [nvdbleek]
Steven: Should we say a should or may in text area?
15:45:45 [nvdbleek]
ebruchez: If you have an html host language then a should is reasonable (a must probably not), but if you have another host language… it kind a makes sense to also support it
15:46:12 [nvdbleek]
Steven: reads text about xs:date
15:46:49 [nvdbleek]
Implementations should provide a convenient means for entry of datatypes and take into account localization and internationalization issues such as representation of numbers. For example, an input bound to an instance data node of type xsd:date might provide a calendar control to enter dates; similarly, an input control bound to of type boolean might be rendered as a checkbox.
15:47:01 [nvdbleek]
Steven: should we use the same kind of wording
15:48:15 [nvdbleek]
ACTION: nick to add the xforms:HTMLFragment data type and add text to the text area control similar like it is done for xs:date on xf:input
15:48:17 [trackbot]
Created ACTION-1939 - Add the xforms:HTMLFragment data type and add text to the text area control similar like it is done for xs:date on xf:input [on Nick Van Den Bleeken - due 2013-03-27].
15:49:49 [nvdbleek]
Steven: xfroms:output could also be amended that it should support html formatting based on the new type
15:51:14 [nvdbleek]
nvdbleek: we shouldn't do anything because the text is already there
15:52:36 [nvdbleek]
ebruchez: The spec only specifies image/* for media type attribute on output.
15:54:05 [nvdbleek]
ebruchez: Is the media type still useful on output?
15:54:56 [nvdbleek]
Steven: when the media type is text/html and the data type is xs:string we render the html, if it is absent it is just a string
15:56:54 [nvdbleek]
nvdbleek: couldn't we just not consider they media type attribute as an extra hint of how to render the output when the type of the data isn't clear
15:57:27 [nvdbleek]
Steven: We leave it as it is
15:57:32 [nvdbleek]
nvdbleek: I think so
15:58:00 [nvdbleek]
ebruchez: I think that it is fine for now, until I come up with something new
15:59:31 [Zakim]
-pfennell
15:59:34 [Zakim]
-Steven
15:59:35 [Zakim]
-[IPcaller]
15:59:36 [Zakim]
-ebruchez
15:59:38 [Zakim]
IA_XForms()11:00AM has ended
15:59:38 [Zakim]
Attendees were Steven, [IPcaller], ebruchez, nvdbleek, pfennell
15:59:59 [Steven]
rrsagent, make minutes
15:59:59 [RRSAgent]
I have made the request to generate http://www.w3.org/2013/03/20-forms-minutes.html Steven
16:00:27 [alain]
alain has left #forms
17:14:12 [Zakim]
Zakim has left #forms