See also: IRC log
<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
<Steven> http://lists.w3.org/Archives/Public/public-forms/2013Mar/0000.html
<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].
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).
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
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]