Forms WG FtF, TPAC Lyon, France, Day 1

01 Nov 2010

See also: IRC log


Steven, Nick, Leigh, Unl, MoZ, Alain, John_Boyer
Steven 'n'Leigh



<unl> Good morning!

Just working out which room this is for Zakim to phone it

<unl> ok

hi Leigh

Trying to work out how to dial out here

Observing: Jaehyuk Choi (LG Electronics)

<scribe> New W3C member

Products using web tech

Not yet decided which groups to join

Observing today

<nick> http://www.w3.org/MarkUp/Forms/wiki/Category:XForms12


Lovely weather here

<nick> http://www.w3.org/MarkUp/Forms/wiki/Category:XForms12

Alain said he will be here around 10.30

Nick wants us t do XPath 2.0 tomorrow

Nick: We have finalised the UI for a new product, and we have custom components, but I owuld like to have Eric on the call. I have more time for the WG from now on
... Some 1.2 features are almost ready
... Dialog
... custom xpath functions

<nick> http://www.w3.org/MarkUp/Forms/wiki/Dialog

<nick> http://www.w3.org/MarkUp/Forms/wiki/Custom_XPath_functions

Producing the spec


<klotz> Mediawiki says [[#See also]]

<klotz> steven

<klotz> http://www.mediawiki.org/wiki/Help:Links

<nick> <a name="Abstract" id="Abstract"></a>

<nick> <a name="1.2_Reading_the_Specification" id="1.2_Reading_the_Specification"></a>

<nick> http://www.w3.org/MarkUp/Forms/wiki/XForms_1.1_in_Wiki#1.2_Reading_the_Specification

<nick> http://www.w3.org/MarkUp/Forms/wiki/XForms_1.1_in_Wiki#3.2.1_Common_Attributes

<a name="1.3_How_the_Specification_is_Organized" id="1.3_How_the_Specification_is_Organized"></a>

<nick> E.g: http://www.mediawiki.org/wiki/Help:Editing_pages

<klotz> http://www.mediawiki.org/wiki/Category:Navigation_extensions

<klotz> some of them show promise.

<klotz> also http://clc-wiki.net/wiki/Planning:Treeview_skin

<klotz> "The skin adds the concept of "pseudo-namespaces" - termed "contexts" or "sub-contexts" - in wiki article titles using colons as separators, and creates a hierarchy out of them. It then displays that hierarchy as a treeview that replaces Monobook's native sidebar navigation pane."




Should be readable now

That is the code that translates wiki format to (X)HTML

The tasks to be done: un-number the Wiki XForms spec (or edit the transform script)

get the transform wiki-xhtml working

3) modularise the XForms 1.1 to get a proto XForms 1.2

back in 20


<klotz> inputmode appendex starts with =<inputmode>

<klotz> i mean starts with =<code>inputmode

<klotz> i posted the update but internal links don't work.



We can do in page links, but we get the "#" in the text

but that is not a particular problem, since we can get rid of them in the transform from wiki to html

Nick is installing Python now in order to try and run the transform code


<klotz> definition links (i.e., #form_control ) don't work. the table has no anchors.

<klotz> the same for external references.




Convert every JSON object to XML

Example of the JSON you get http://en.wikipedia.org/w/api.php?action=opensearch&format=json&search=saturn

<nick> http://lists.w3.org/Archives/Public/public-forms/2010Mar/att-0037/2010-03-26.html

The ideal solution would make the difference between JSON and XML opaque

For arrays, Alains uses extra <item> elements

Nick: Picoforms just repeats the element

Alain: The problem is distinguishing empty arrays, one-element arrays in the general case

Steven: Serialization/round tripping means that we have to have a one-to-one mapping\

Nick: In XML you would write a/f[1], but for the JSON version we would have to write a/f/item[1]

Alain: That's why I want to extend the XPath engine
... Using the 'item' method, it was quick and easy, and no changes to Xpath

<Peter> Steven: thanks

Nick: Downside is that the authoring is different
... ought to be easier

Steven: If the serialization is the problem, couldn't we do:

<a> <f json-array="yes">...

for the a/f[1] ase

<klotz> there are conflicts in refs in the structures "mediatype" for example.

Now addressing the problem of different characters in json names, not allowed in XML, such as $foo

Alain: Maybe encode them in a standard way, base 64 or something
... With shortcut such as a/json_el('$foo')
... which would need XPath 2.0

Nick: That would be a nice shortcut for authoring

<Peter> Nothing specific, I'm mostly being curious. Learning about subjects I'm currently not familiar with always is a good thing, and I figured reading the discussions at TPAC would give me insight in where XForms will be going

Steven: We could use a/*[json-name="$foo"

with an instance that looks like <a><foo json-name="$foo"

which works, requires no new function, works with XPath 1.0, and covers the corner cases

Nick: Also works with $foo and *foo in the same document

<klotz> why not use mips? they're 100% not going to have a name conflict

Alain: Performance might be affected

Steven But it is an edge case that won't arise often in parictise surely

explain Leigh?

Leigh: unnamed arrays?

<nick> <a><_foo json-name='$foo'></_foo><_foo json-name='$foo' json-array='true'></_foo>

<nick> <a><_foo json-name='$foo'></_foo><_foo json-name='*foo' json-array='true'></_foo>

Nick: We identify three attributes - is it na array, is it anonymous, what is the json anme

Leigh: The parser can record its own MIPS as it reads

Nick: Only problem is with selecting within XPath if those MIPS are hidden

Leigh: The advantage of the MIP over the attribute version is name clashes

Steven: But there are no attribute name clashes with a JSON instance, since there are no attributes in JSON
... Certainly the MIP is good for the array problem
... leaving the only problem with the odd characters in JSON names

<klotz> path/to/jsonname('foo bar')/el[3]

<klotz> path/to/*[jsonname('foo bar')]/el[3]

Nick: You could write:
... <a><f1>...<f2>...
... <bind nodeset="f1" json-name="$foo"
... json-array="true()"

<klotz> i wasn't following the problem statement so I thought attribute name conflicts would be a problem; it's not clear to me that attributes + functions isn't a good enough solution.

Nick: And for the anon case use json-name=""
... You only have to do this if you are creating the instance yourself
... for the case of arrays with more than one element, the problem is not there

Steven: Where do we say what sort of serialization we have?
... And I would like to generalise to other formats, eg http://tools.ietf.org/html/rfc5546
... generalise="make sure it works in more cases than just JSON"

Alain: So we could use @fullname instead of @json-name

<klotz> http://www.yaml.org/

<klotz> http://jsync.org/ - JSON+YAML

Steven: So you have the problenm of where you create the instance, of specifying the serialization used. Which means a new sattribute on <submission>

<klotz> http://en.wikipedia.org/wiki/JSON#Windows_Registry_language_and_.ini_files

<klotz> or submission/@serializer

Nick: In cases you may want to override the mimetype, if it is wrong

<klotz> you need to specify the serializer in addition to the mediatype, if there are different ways to serialize the same mediatype.

Nick: and you need it for serialization and for parsing

Leigh: Do we need more than one JSON serialiser?

Steven: I believe we have covered all cases now

Leigh: The question is whether mime type is enough to identify the serialiser

Steven: The mime type should be enough; let us assume that for now until we find a counterexample

Nick: For VCARD support we don't need any extra attributes
... Maybe extra formats should be separate specs
... if they don't affect the definition of XFORMS

S/01they would be leight-weight/they would be leight-weight/

Steven: ANd we don't have to reissue XForms to allow for more formats

Alain: And how about allowing JSON notation in the xforms instance

Nick writes:

<div id="mydef"

a={ .... }


<instance src="#mydef" mediatype="text/json">

(or whatever)

Alain: or allow directly in instance element

Nick: Who owns this?

Steven: I had said I'd take it over, but I don't mind if someone else would rather own it

We will try to retunr in one hour for a 3 hour session

<scribe> scribe: Steven




Alain: I'm using the function approach successfully

Nick: I prefer the function approach

Alain: It is implemented in XSLTForms
... we sorted out the problems for the dependencies

John: How does that work?

Alain: When a node changes, we consider all its ancestors changed
... not that slow
... even with heavy transforms

John: What is the function signature?

Nick: The function won't reevaluate if descendants change

Alain: It is the same for all functions

Nick: Will also work for the ID function
... if you change a node, you walk up the ancestors and mark those

<John_Boyer> transform('my-stylesheet.xsl', instance())

\steven: Same as we did on our Views system in the 80's

Nick: In your instance() example John, when anything in the instance changes, it will restart the transform

John: How about forms with elements and attributes?

<John_Boyer> <price currency="blah">10</price>

John: Changing @currency means that price is marked?

Nick: Yes

John: I'm just watching for circular dependencies

Nick: There will be no value-changed event sent if the value doesn't change

<John_Boyer> <element a="2" greater="" b="1"></element>

<John_Boyer> <xforms:bind calculate="if(@greater = 'a', @a, @b)" readonly="false()" nodeset="element"></xforms:bind>

<John_Boyer> <xforms:bind calculate="if(../@b &gt; ../@a, 'b', 'a')" readonly="false()" nodeset="element/@greater"></xforms:bind>

John: We might have to change how 1.1 describes dependencies

Nick: we aren't adding extra dependencies
... just simulating extra value changes

<John_Boyer> id('X')

<nick> id('X Y', instance('Z'))

<John_Boyer> <e id="X">a</e>


[Example shows it works for 2 param version if id() as well]

Steven: Do we resolve to go wih the fucntional version?

of transform

John: What is the returned value?

Alain: Now it is a string

<John_Boyer> transform gens a string, which one could choose to parse with http://www.w3.org/MarkUp/Forms/wiki/Parse_Serialize_functions

<John_Boyer> use with output seems to need the string version of transform

Nick: The best result would be a sequence, for XPath 2.0

<John_Boyer> <output ref="transform(blah, blah)" mediatype="text/html"> ...

<John_Boyer> What should this do?

Nick: The transform function says what the output is, text or XML
... so Ideal is to keep that possibility
... otherwise you have to do the parse again
... but an XPath 1.0 would always return the string

<John_Boyer> XPath 1.0 could retjurn an "object"

<John_Boyer> which could be a string or nodeset

<John_Boyer> (or number or boolean, but the main idea is that xpath 1.0 could also support an ambiguous return type)

Alain: with submission you want the result to be serialised
... transforming the serialisation, and then reserialising it is silly
... I would to have to find a trick to avoid this

Steven: Can we decide to go with the functional version?

Nick: John had the problems with htat approach

John: We've dealt with the update problems. What about in a UI binding?

Nick: We could disallow it there

John: We might be able to find a solution to the UI bindings

<John_Boyer> Maybe there are no problems with <output ref="transform(...)" ...

<John_Boyer> <output value="transform()" mediatype="text/html"...

Nick: We could regard a UI binding as creating new nodes

<John_Boyer> <repeat nodeset="transform(...)/blah">

<John_Boyer> <input ref="foo/bar"

John: You would lose everything if the transform gets reevaluated

<John_Boyer> maybe it's just "don't do *that*"?

Nick: You would lose the repeat-index
... as well

John: Using repeat to iterate over a transform would be a bad idea. Better to save the transform in an instance and use that

<John_Boyer> repeat containing outputs would be neat, though, just to *show* a table of data

<John_Boyer> though, repeat is itself a mini-transform

Alain: Disable delete buttons

Nick: But the result of a transform would be readonly so the delete buttonjs would be styled as readonly
... Does readonly work the same as how it works on group

John: yes


<John_Boyer> <bind nodeset="transform(...)" readonly="false()"/>

Nick: You'd be Bad if you did that

<John_Boyer> What about <input ref="tranform(...)/x/y/z"?

<John_Boyer> seems it is insufficient to restrict tranform() from being used in nodeset bindings only; seems better to just say result nodes are readonly


John: Making them readonly sounds the best
... does that also work for all other node creation functions we've been talking about?

Nick: Sounds right

John: parse() and create() are the only other two
... what are the usecases for parse()?

Nick: functions that return strings

John: Oh yes, to use as the @origin of insert
... so that works
... and the create() function

Nick: Also for insert

John: OK, also for @origin. Cool
... so we can conclude that node creation functions should mark the result as readonly
... and when a node changes we need to mark the ancestors as changed as well

Steven: I prefer 'dirty' to changed

John: Right

Steven: Changed implies value-changed to me

John: Looks good


RESOLUTION: Use the function version of transform

<John_Boyer> yes

Nick: We may need to add to the spec that functions with an optional last parameter, when the last param is missed, you use the current context, which becomes an implicit dependency

Alain: Implementation issue

Nick: Make it explicit at least

<John_Boyer> In http://www.w3.org/TR/xforms11/#expr-dependencies, we say that a reference happens when a node is selected by matching a node test or when returned by a function call. Looks like not just an implementation issue

Alain: To go back to transform(), I was considering inline stylesheets for small transformations

<nick> http://www.w3.org/MarkUp/Forms/wiki/Transform

Alain: depending on the first paramater - a string a URI, a node a stylesheet

<nick> #my-stylesheet

<nick> transform('#my-stylesheet', instance())

Nick: That is in the base document

John: Instance data is in a separate document

<John_Boyer> <html> ... <xf:instance> ... <e id="my-stylesheet">something that changes</e>

Nick: That would give the original instance

<John_Boyer> from the source document, not from the live instance data

<style id="my-style" type="application/xslt+xml">....

would be a more general use

Nick: Then you wouldn't need the nodeset as first param. A string would be enough

Custom controls

Nick: We are doing custom controls, so are Orbeon, and Alain, and I would like to align them

[demo time]

<nick> <idfc:adf-progress nodeset="instance('job-stages-status')/stage-runtime-info" status="@status">

<nick> <xf:label ref="@name"/>

<nick> <idfc:icon><img src="{{if (exists(index-of(('Print' , 'Compose', 'Finish', 'Deliver', 'GeneratePrintFile'), @name))) then concat('../images/', @name, '.png') else '/xbl/inventivedesigners/adf-progress/img/stage.png'}}"/></idfc:icon>

<nick> <idfc:info>

<nick> <table>

<nick> <tr><td class="label">Start</td><td><xf:output value="format-dateTime(@start-date, '[Y0001]-[M01]-[D01] [H]:[m01]:[s01]')"/></td></tr>

<nick> <tr><td class="label">Completion</td><td><xf:output value="format-dateTime(@completion-date, '[Y0001]-[M01]-[D01] [H]:[m01]:[s01]')"/></td></tr>

<nick> </table>

<nick> </idfc:info>

<nick> <idfc:actions>

<nick> <!-- Only show the complete actions when you are an operator and the job-profile is OperatorJob -->

<nick> <xf:trigger ref="self::node()[$is-operator and instance('default-instance')/job/@job-profile = 'OperatorJob' and exists(instance('job-external-stages-waiting')/stage[@stage = context()/@name])]" appearance="minimal">

<nick> <xf:label value="$translation/misc/mark-completed"/>

<nick> <xf:action ev:event="DOMActivate">

<nick> <xf:setvalue ref="instance('release-stage-instance-req')/stage" value="context()/@name"/>

<nick> <xf:send submission="release-stage" mode="synchronous"/>

<nick> <xf:dispatch name="update-details" target="model"/>

<nick> </xf:action>

<nick> </xf:trigger>

<nick> </idfc:actions>

<nick> </idfc:adf-progress>

Nick shows an xbl custom control

Alain: I like the xbl approach
... we really need to be able to do rich controls

Nick: Orbeon has a lot of extra controls

Alain: Interoperability is a problem though

Steven: How do we move further on this

John: What does XForms need extra to support this?

Nick: Not much

Steven: So if you have xbl, you don't need additions to XForms.

Nick: The current status of xbl is unclear at the moment

Steven: Assume for the present that the new edition hasn't happened

Nick: In xbl you just copy over the attributes, but sometimes you want to be more specific, and XSLT is handy for that; that's a limitation of XBL

John: So nothing needed in core XForms?

Nick: Right
... Sometimes you would like to have submodels
... Orbeon does it by communicating through events

John: We got components to talk to each other using a wiring concept
... and javascript versions of setvalue insert and delete
... our DOM interface doesn't expose the logical equivalent of setvalue insert and delete

<John_Boyer> http://www.w3.org/TR/xforms11/#expr-instance

<John_Boyer> http://www.w3.org/TR/xforms11/#idl-getInstanceDocument

Steven: You mean an interface that interfaces with the constraint system?
... Please send in a change request for such an interface and we can discuss it

<John_Boyer> in a "wire" from component A to component B, the xforms-refresh on the model in component A would activate the wire and push data to component B. The implementation of the wire would do logical equivalent of setvalue, insert/delete on B, which would then cause the usual [rebuild] recalculate revalidate refresh on B

<John_Boyer> could use a finer grain event than xforms-refresh

<John_Boyer> something that allows wiring of a small subtree of component A to component B, but without fine grain, it was still workable

<John_Boyer> didn't really need submodels, for example

Nick: In my example form here, there is a pipeline of 4 stages, and these are all custon controls, actually a repeat over an instance
... so if the instance had 5 stages, the instance would have 5 elements

John: So you don't need to use events to communicate, since you're just using the normal constraints

<John_Boyer> http://www.w3.org/MarkUp/Forms/wiki/ModelEnhancementRequirements

Externally defined models with src attribute

John: I thought we had decided to us xinclude for this use case

Steven: In that case we should annotate the page with that decision
... I would prefer to leave it in the category XForms12 though, just so we have a record

Coming days

Steven: Nick and I will be working on getting the spec production tools working this week
... we plan to work on it first thing each morning, as most people will be joining later


Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/11/01 15:58:42 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Godd/Good/
Succeeded: s/ca.../call./
Succeeded: s/for/form/
Succeeded: s/SteveL/Steven/
Succeeded: s/na/an/
Succeeded: s/bin/bind/
Succeeded: s/mometype/mimetype/
Succeeded: s/LY/Ly/
Succeeded: s/THEY WOULD BE LIGHT-WEIGHT/they would be leight-weight/
Succeeded: s/signature/signature?/
Succeeded: s/ent/ant/
Succeeded: s/tes/tes?/
Succeeded: s/s how/ show/
Succeeded: s/ s / if/
Succeeded: s/if/if /
Succeeded: s/lost/lose/
Succeeded: s/relevance?/ how it works on group/
FAILED: s/\\;/:/
Succeeded: s/\;/:/
Succeeded: s/\john\;/John: /
Succeeded: s/()/()?/
Succeeded: s/|//
Succeeded: s/xml+xsl/xslt+xml/
Succeeded: s/ebn/en/
Succeeded: s/this/this?/
Succeeded: s/bein/beon/
Found Scribe: Steven
Inferring ScribeNick: Steven

WARNING: Replacing list of attendees.
Old list: unl Leigh_Klotz Roseraie_2 John_Boyer
New list: Roseraie_2 John_Boyer unl

Default Present: Roseraie_2, John_Boyer, unl
Present: Steven Nick Leigh Unl MoZ Alain John_Boyer
Got date from IRC log name: 01 Nov 2010
Guessing minutes URL: http://www.w3.org/2010/11/01-forms-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]