See also: IRC log
Hi!
<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
http://www.w3.org/MarkUp/Forms/wiki/XForms_1.1_in_Wiki
<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."
http://www.w3.org/TR/2009/PR-owl2-profiles-20090922/
http://www.w3.org/MarkUp/Forms/2010/revdoc/readme.txt
http://www.w3.org/MarkUp/Forms/2010/revdoc/
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.
http://www.w3.org/MarkUp/Forms/wiki/XForms_1.1_in_Wiki
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
http://www.w3.org/2007/OWL/wiki/Round_8
<klotz> definition links (i.e., #form_control ) don't work. the table has no anchors.
<klotz> the same for external references.
http://www.agencexml.com/jsoncallback/wikipediasearch.xml
nodeset="instance('iresults')/item[2]/item">
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
... THEY WOULD BE LIGHT-WEIGHT
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={ .... }
</div>
<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
http://www.w3.org/MarkUp/Forms/wiki/Category:XForms12
http://www.w3.org/MarkUp/Forms/wiki/Transform
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 > ../@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>
http://www.w3.org/TR/xforms11/#fn-id
[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
s/\:/:/
<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
http://www.w3.org/MarkUp/Forms/wiki/Nodeset
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
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
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
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
[ADJOURN]
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]