W3C

- DRAFT -

Forms Working Group Teleconference

20 Mar 2013

Agenda

See also: IRC log

Attendees

Present
Steven, [IPcaller], ebruchez, nvdbleek, pfennell
Regrets
Chair
Steven
Scribe
nick

Contents


<trackbot> Date: 20 March 2013

zaki, code?

<pfennell> Joining the call in a minute.

<Steven> We'll start when you get here

<scribe> scribe: nick

Reminder - Call times back to normal next week

<Steven> http://lists.w3.org/Archives/Public/public-forms/2013Mar/0000.html

Orbeon Forms 4.0

<Steven> http://lists.w3.org/Archives/Public/public-forms/2013Mar/0008.html

http://lists.w3.org/Archives/Public/public-forms/2013Mar/0008.html

Steven: congratulations with the release

<Steven> ACTION: Steven to add Orbeon announcement to home page [recorded in http://www.w3.org/2013/03/20-forms-minutes.html#action01]

<trackbot> Created ACTION-1938 - Add Orbeon announcement to home page [on Steven Pemberton - due 2013-03-27].

[ACTION-1934] Completed (Update the XML and relax-ng schema (change

mediatype to accept on upload))

http://lists.w3.org/Archives/Public/public-forms/2013Mar/0013.html

Steven: Erik you commented it

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.
... If you see the diff

<ebruchez> https://dvcs.w3.org/hg/xformsusers/rev/79a8870aa69c

<Steven> reopen action-1934

<trackbot> Re-opened ACTION-1934 Update the XML and relax-ng schema (change mediatype to accept on upload).

textarea/@mediatype and Rich Text Editors

http://lists.w3.org/Archives/Public/public-forms/2013Mar/0011.html

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

Steven: Alain said that a media-type isn't enough

alain: There are different kind of editors
... They want to say which options they want

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)

alain: Users want different editors

nvdbleek: On the last call we kind of agreed that it should be type based, similar to xs:data for a date control

alain: In xsltforms there is a way to associate types with widgets

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

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

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

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

<ebruchez> xforms:html

ebruchez: If we want it to be data type driven we need to come up with a xs datatype

Steven: in his email he said it as a restriction of a datatype

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

Steven: We could also go for both, in the model and on the control

alain: I like the the standard datatype for html
... in XSLTForms you will still have the way to specify the widget to use by restricting xforms:html

ebruchez: Would we require any validation on that datatype?

Steven: if the validation differs between implementations then some implementations may submit html that other implementations not
... most widgets do a fragment not a whole document

ebruchez: We could say that implementations aren't required to do any validation checking, but are they allowed to validate the content

Steven: any string that you submit to a browser gets displayed
... So we shouldn't require that it is well-formed, ….
... We shouldn't require that it is validated

ebruchez: it is very hard to validate if something is valid html

<ebruchez> (it's hard to find a way to specify it)

Steven: how does XSLTForms handle validation on html widgets?

alain: Everything the widgets makes is valid html

Steven: the xforms:html can't be invalid (all values are valid according to the xforms processor)
... The proposal is to add new data type, do we call it xforms:HTMLFragment

<ebruchez> xforms:htmlFragment

<ebruchez> xforms:HTMLFragment

Steven: no extra validation (any string is valid)
... The widget may guarantee to always generate valid HTML

RESOLUTION: Add a new xforms data type xforms:HTMLFragment that will trigger a rich text editor

nvdbleek: does it work for input or only textarea?

ebruchez: input is single line input, text area is multiple lines
... but we have the use-case were we want on line with only bold, italic and links

Steven: Should we say a should or may in text area?

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

Steven: reads text about xs:date

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.

Steven: should we use the same kind of wording

<scribe> 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 [recorded in http://www.w3.org/2013/03/20-forms-minutes.html#action02]

<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].

Steven: xfroms:output could also be amended that it should support html formatting based on the new type

nvdbleek: we shouldn't do anything because the text is already there

ebruchez: The spec only specifies image/* for media type attribute on output.
... Is the media type still useful on output?

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

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

Steven: We leave it as it is

nvdbleek: I think so

ebruchez: I think that it is fine for now, until I come up with something new

Summary of Action Items

[NEW] 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 [recorded in http://www.w3.org/2013/03/20-forms-minutes.html#action02]
[NEW] ACTION: Steven to add Orbeon announcement to home page [recorded in http://www.w3.org/2013/03/20-forms-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2013-03-20 16:00:05 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/xforms:htmlfragment/xforms:HTMLFragment/g
Succeeded: s/xforms:xhtmlFragment/xforms:htmlFragment/
No ScribeNick specified.  Guessing ScribeNick: nvdbleek
Found Scribe: nick
Default Present: Steven, [IPcaller], ebruchez, nvdbleek, pfennell
Present: Steven [IPcaller] ebruchez nvdbleek pfennell
Agenda: http://lists.w3.org/Archives/Public/public-forms/2013Mar/0014
Found Date: 20 Mar 2013
Guessing minutes URL: http://www.w3.org/2013/03/20-forms-minutes.html
People with action items: nick steven

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]