Forms Working Group Teleconference -- 06 Feb 2008

<trackbot-ng> Date: 06 February 2008

<Steven> Scribe: Mark

Agenda Review

<Steven> scribenick: markbirbeck

John: Agenda will mainly be circling back to 1.2 features.

<Steven> Meeting: Forms WG FtF Raleigh, NC, USA, Day 3

Charlie wanted to briefly discuss Erick's post about the name RIA.

Suggested that he was right, and that we should avoid references to "rich internet applications".

Some agreement.

<John_Boyer> http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html

John: Last night worked on the spec.

<John_Boyer> http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#structure-bind-element

John: Made some changes to the bind element to capture some of Aaron's comments.

Custom Functions

John: Mainly clarified that the default nodeset is obtained from the default evaluation context. This was needed since @nodeset is optional on xf:bind.

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

John: Also looked at the custom XPath function requirement. May not yet be right, but looks promising.
... Examples are followed by some notes and questions that came up whilst looking at the issues.

Mark: Point out in passing that this is why I argue that the feature-set of XBL can more easily be done in an XHTML container.
... I.e., the <function> element can define methods that could be called within the XHTML document, but it could also express a method that is a public interface for a widget.

John: Started playing the idea of having internal or temporary instances, but it gets awkward when you start trying to return nodesets to the caller.
... but the idea of variables seems to capture this better, and is interesting that this seems to converge with some of yesterday's discussions about simplification.

Leigh: What causes the actions in the function to run?

John: It's just like normal, in that xf:actions don't 'run' until an event is dispatched to it.
... In these examples the actions run when the function is invoked.
... Also considered putting the implementation into a specific element.

Mark: Pointed out that there is a handler spec in XHTML-world that does a lot of this. Should look at trying to merge the two.

John: Variables are a bit like actions.

<klotz> is there a link for the XML Handlers document?

Mark: Should have a flag that indicates whether the function's operation requires a rebuild.

John: At the moment everything is ring-fenced, so can't modify the wider data.
... Open questions like should we set the return type? Should <return> be in only one place, or be allowed to appear anywhere?

<Steven> Leigh, http://www.w3.org/TR/xml-events/#s_handler_module_elements

<klotz> OK, so it finally made it into XML Events 2.

<Steven> yes

<nick> http://www.w3.org/TR/xslt20/#element-function

<Steven> Mark: Well you can imitate a function in XForms using an instance and events

<Steven> ... so we just need to package that as a function call as syntactic sugar

<klotz> yes, but i can see now xsl:function doesn't allow actions or script, just a value-of.

John: Recursion may not necessarily be a problem, but modifying data may be an issue.
... XPath functions are not meant to modify the data that they are running against.

<klotz> xslt2.0 functions are recursive

<klotz> http://www.ibm.com/developerworks/xml/library/x-xdxslt20.html#code4 factorial

Mark: Should consider either copying the model of the xsl:function definition, or extending the handler module.
... What a pity that there is no module we can import.

Nick and John discuss some of the details of the XLST 2.0 definition, such as override, return types, etc.

John: How do values get returned? Surely we can't do the same as the XSLT technique?

Mark: We could (i.e., accumulate nodes for returning as the function is executed) but it may not be the best way to do things for our audience.

Nick: Need to be able to us xf:insert and xf:delete whilst constructing the result set.

<John_Boyer> <insert name="somenodesetvar" origin="$p"/>

<John_Boyer> <insert name="somenodesetvar" origin="$p[some condition]"/>

Mark: But you need to be able to manipulate the variable itself.
... For example, <insert nodeset="$people[3]" origin="$p[some condition]' />

<John_Boyer> <variable name="people3" as="nodeset" value="$people[3]"/>

Mark: No. :)
... In XPath 2.0 you can create nodesets on the fly.
... I'll type a rough approximation for Nick to correct. :)
... <variable name="people" value="{ 'a', 'b', 'c' }" />

John: But this limitation is right, since you shouldn't be allowed to modify the passed in data.

Mark and Nick: But you need to be able to return values that are not just numbers (as in the examples_.

Mark: There is no distinction from an XPath point of view between some simple type like a number, and a node or even a nodeset.

<John_Boyer> <function name="foo" as="nodeset">

<John_Boyer> <param name="p" as="nodeset"/>

<John_Boyer> <param name="q" as="nodeset"/>

<John_Boyer> <variable name="r" as="nodeset"/>

Nick: The new insert action allows us to do everything we would need to do to manipulate this nodeset.

<John_Boyer> <insert name="r" origin="$p[somecondition]"/>

<John_Boyer> <insert nodeset="$r[somecondition]" origin="$q[some condition]"/>

<John_Boyer> <insert name="r" at="4" position="before" origin="$q[some condition]"/>

Also <xf:setvalue ref="$r[3]/@long" value="convertGeo($o[3]/@long, 1)" />

John: Need to decide whether we allow anything within functions, or make it limited.

Mark: Not quite saying that authors should be allowed to do anything, just saying that authors should be allowed to manipulate the variables.

John: Realise the disconnect is that you are talking about manipulating the nodeset object as a tree, not just a flat list of values.

Mark: These problems have been solved by XPath 2.0 and XSLT 2.0, such as recursion, etc. So we're not inventing anything.
... Creating XPath functions is an establishing thing, all we're looking for is how to do it in our language.

John: But XSLT 2.0 _is_ different in that they have an input tree and an output one.

Mark: But that doesn't affect what an XPath function has to do; they just use XSLT 'concepts' to create an XPath function, and we would use XForms concepts to do the same. But either way you return a nodeset.

<klotz> i cant' hear anybody; is this a break?

<klotz> ok thanks;

<John_Boyer> <setvalue ref="foo(nodes)" value="5"/>

<John_Boyer> foo picks a node from the set of nodes and returns it

Mark: This is good stuff, but it doesn't address the low-hanging fruit of existing JavaScript functions that can be used in many processors.
... e.g.,:
... <html xmlns:inline="some formsPlayer namespace">
... <script type="...">
... function geocode(long, lat) {
... return x;
... }
... </script>

<Steven> jturner, hi

<jturner> hi

<Steven> forgotten anything?

<jturner> yup ;)

<John_Boyer> missing U in Raleigh :-)

Mark: <xf:setvalue ref="a/result" value="inline:geocode(../@long, ../@lat)" />

<Steven> Welcome to day3 of the FtF

<jturner> sorry

<John_Boyer> <function name="geocode">

<John_Boyer> ...

<xf:model functions="geo:code">

<jturner> bad line

<jturner> try again

<John_Boyer> xforms NS URI#functions

<John_Boyer> xforms NS URI#script-functions

Mark: The same mechanism would be used to reference a function defined in the new 'full' way that John is proposing, should that function not have a namespace prefix.
... e.g., <function name="sumproduct" as="number">
...
... </function>
... <output context="/purchaseOrder/items" value="local:sumproduct(item/price, item/quantity)"/>

<John_Boyer> xmlns:local="&xformsNS;#local-functions"

Proposal to add a new namespace that will identify local/user-defined functions in a document, regardless of whether they are defined using script (as Orbeon, formsPlayer and we think, PicoForms allows) or the new function element.

<John_Boyer> http://www.w3.org/2002/xforms

Proposal to set the namespace to "http://www.w3.org/2002/xforms/inline-functions#".

<klotz> dont' we have to ask for namespaces?

<inserted> /www.w3.org/MarkUp/Forms/wiki/Custom_XPath_functions/Topic: Custom Functions

Sorry...I meant 'to set the namespace to "http://www.w3.org/2002/xforms/local-functions#"'.

Nick: Why have the hash at the end?

Mark: Helps in RDF-world.

<Steven> rsagent, make minutes

<klotz> for string composition to express qnames

To make URIs, Leigh. :)

Leigh: Don't we need to ask for a namespace?

Steven: Not sure that we do, since we are extending into our own space.
... (Into our own 'URI space').

<Steven> I'm asking in the W3C channel

<Steven> tho' IanJ is not there, so I may not get an answer

Mark: Don't want to say "trust me guys", but this is best practice.

<shepazu> be there shortly

<Steven> k

John: Why don't we use # before 'local-functions'?

Leigh: You need to concatenate two things.

Mark: Think of an example...e.g., local:myfunc.
... what does that represent?
... We're defining something that does at the beginning.
... Best practice is to create a 'good' URI.
... This would generate:
...http: //www.w3.org/2002/xforms#local-functionsmyfunc

<klotz> # is better than / for a purely pragmatic reason that it's easier to see and people are less likely to accidentally leave it off.
...http: Not nice....
... Point is to create an RDF-friendly identifier. People may never use it, but that doesn't matter.
... So http://www.w3.org/2002/xforms/local-functions#myfunc
... or http://www.w3.org/2002/xforms/local-functions/myfunc
... is preferable.
... would propose using hash, and also that we use the singular.

<Steven> I have received a message that it is OK to extend our NS URI without having to ask for permission

<klotz> thanks Steven

Proposal: to use the namespace "http://www.w3.org/2002/xforms/local-function#" to identify author-defined functions.

RESOLUTION: To use the namespace "http://www.w3.org/2002/xforms/local-function#" to identify author-defined functions in a document, wether they are defined inline with script or using the proposed function element.

<Steven> Link to train we saw day before yesterday

<Steven> http://en.wikipedia.org/wiki/Circus_train

The topic of the break?

Trains.

(And circuses...but mainly trains.)

<jturner> seems it doesn't make sense to listen to a train break - talk to you next time

<Charlie> http://www.w3.org/MarkUp/Forms/wiki/Make_model_optional

Optional Model

Discussed ending at 4pm.

<Charlie> http://www.w3.org/MarkUp/Forms/wiki/Make_model_optional

(For Leigh's benefit...we're ending two hours earlier than planned.)

<Steven> one hour I think

Charlie: Two examples: A simple form that uses form as an abbreviation for model+instance+submission, and one that gradually adds a few more things to this.

Uli: Is this the same as the HTML form element, or something different?

Nick: Lazy authoring already gives us a lot of what this example shows.

Charlie: How could it be the HTML forms element?

<John_Boyer> I had thought better use of default namespace to XForms would allow no namespace qualification of the elements in the form.

Mark: Because this came originally from our discussions in Venice, about making HTML elements into a shorthand for XForms constructs.

<John_Boyer> I also thought we would use the name attribute rather than ref

<John_Boyer> What about <form xmlns="&xformsNS;" action="...">

<John_Boyer> <input name="field1" ...

<John_Boyer> <input name="field2"...

<John_Boyer> or <input name="field2 calculate="$field1 + 50"

Nick: Isn't form just another grouping element?

John: But this is about reusing the elements.

Nick: Why do we add an element with the name 'form', just because it exists in HTML?

John: But we are the form working group.

Mark: But it makes it easier for people to move from HTML.

<John_Boyer> time for lunch...

<klotz> dialing

<klotz> nobody. only snatches. It seems like it's cutting out and ony turning on when it hears enough audio. if everybody laughs i hear that. i hear about 20% of charlie.

<klotz> ok if you want to talk to me please shout and i will look at the IRC.

<John_Boyer> ok, will do...

<klotz> ebruchez the audio problem is back and they can't fix it.

<ebruchez> ouch

<ebruchez> annoying

<klotz> i answered one of your customers about select/copy.

<klotz> it seems to default to us on the phone talking and you listening, and only when the volume on your side gets high enough does it switch over and we get to hear you; it's half-duplex, and the default seems to be wrong.

<klotz> i don't think that's it. there's no noise, just utter silence, but when several of you talk at once, everything comes through clearly.

<Steven> Well, there's a constant background noise from the fans, so that may define the background cutoff point for the noise elimination filter, and so drowns us out, and gets replaced with silence

<John_Boyer> ACTION: John to send his XML events commentary to public-webapi@w3.org with subject DOM 3 events [recorded in http://www.w3.org/2008/02/06-forms-minutes.html#action01]

<trackbot-ng> Sorry, amibiguous username (more than one match) - John

<trackbot-ng> Try using a different identifier, such as family name or username (eg. jkugelma, jboyer)

<John_Boyer> scribe: Steven

steven

Optional model (continued)

John: I dunno
... I agree with Mark
... a strong emphasis is to make it much easier for people who have developed HTML skills to relate to our markup
... and to map how they spell things now to XForms MVC constructs

Charlie: I wasn't exactly doing that
... though I agree they need to be pulled together

John: That's ease of authoring pattern
... but you wanted optional model in isolation

Mark: I would merge the two
... we need to decide if we need to adopt this philosophical approach
... making the markups look spookily similar

Nick: If we want to do that then we should consider it as a dialect as XForms
... some of it makes it more complicated not less

Mark: If we get it right, it needn't be

Charlie: We have three starting pointds; HTML author, XForms author, but also the one who wants to go backwards from the glass

Mark: If you try to make HTML into XForms
... and gradually add more and more stuff
... such as making model optional
... then <div></div> is a valid XForms
... and you have to define what it means to leave out the instance

John: What if I just add an input?

Nick: Then it creates an implicit model
... an implicit instance
... implicit binds and just works

Mark: It is conceptually an XForms doc, it uses the XForms architecture

Steven: What W3C needs, and we've been saying this since 1999 is something like CSS that layers the meaning
... then we define the XForms semantics and layer it onto XForms markup, Yahoo's blueprint markup, onto HTML and so on

[argument about whether <input name="" is a binding]

John: web developers don't like having to write xf:input and ref=""

Mark: Nick, it is because you come from the XSLT world that you think that the exact spelling of features is not important

Nick: Well, don't we need valid XML anymore?

John: It's to take to the Forms TF, to find common ground

Mark: We have to define what <input name= means in XForms parlance, in order to allow incremental additions like output

Nick: Now I have to explain to people that they can use name or ref

Mark: No
... we just claim that <input name= is in our architecture, but XForms people don't have to use it

Nick: I think it adds confusion

Mark: People need to just learn the most appropriate parts of the language for them

Uli: Doesn

't this mean that an XForms processor has to process any HTML form?

Mark: It could do

Uli: and mixed up with HTML markup?

Mark: Why not?
... HTML5 has added an output element
... If we had the document itself as data model, like we discussed yesterday
... then you could have a hint with data from the alt attribute of an img

John: If you have no model, then what else could you use for your data?

Mark: Exactly

Nick: I don't disagree that it would be a good idea to have the HTML dialect of XForms, but it is just a dialect.

John: I think that people struggle with the attribute being called something different

Steven: I disagree
... I think that the problem is with namespaces; people aren't stupid enough that they can't deal with using ref, and understanding that it represents more than just a name
... but if their first attempt doesn't work because they got the namespace wrong
... that's where it goes wrong

Nick: I think we need to keep the core language simple

Mark: I agree, picoforms won't be interested in this stuff

Nick: it is important that the same syntax should produce the same results

Mark: As STeven said, what we are really talking about is the XForms architecture
... not particular markup
... so getting the concepts right is more important than the concrete syntax

Mark; So does <form> generate more content, or does it map to stuff we already have

scribe: then svg could add an input to SVG without using <xf:input>

Steven: So what we are doing is rejecting namespaces as the mechanism for combining archtectures, and what we have to do is start a new WG to develop Architectural Style Sheets

[laughter]

Charlie: Well, that's XBL

Steven: Not sure, XBL is a bit too concrete

Mark: [Something about events and lifecycle that the scribe missed]

Charlie: I wonder if we can abstract events out, so that people could use another event mechanism

Mark: Events are really like a method interface
... but to get these things working together, you need one thing that is concrete
... that you can be certain that you can talk to other things through that interface

Charlie: You lose the Ajax people if you say that

Mark: Dojo has 4 different event mechanisms, DOM2 is one of those
... but IE doesn't support DOM2 events natively, the rest do
... so on IE you have to script it
... but you still need the event object

Charlie: You can do everything just using target phase
... which is what SMIL does

Mark: You can do that with hint as well
... you listen to the mouseover directly
... rather than converting to the hover event

<markbirbeck> http://www.w3.org/2004/04/webapps-cdf-ws/papers/webapps-workshop-standards-based-vm.pdf

Charlie: So how do we do this architectural thing?

mark: See my paper from 2004

[laughter]

Nested Models

<Charlie> http://www.w3.org/MarkUp/Forms/wiki/Example_markup_for_nested_models

Charlie: My airline seems to be prefilling data on some forms to make life easier on a mobile device
... so this markup shows a similar interface

Steven: What is the advantage of nesting rather than having siblings?

Charlie: Context
... it solves a number of the cross model referncing problems

John: But you could do <model src="" to achieve the same effect

Charlie: I tried to avoid things like that

[for reasons that the scribe missed]

John: The UI is not allowed to talk to the inner model, which is interesting

Charlie: Nor the inner submissions

Mark: Why do you want to hide them?

Charlie: Black boxes

Mark: Then leave the id off
... it makes implementing the hiding easier
... But it is a good model
... it gives a public face without having to know the instance structure
... If you want to make an importable model, then you would have to avoid id's to avoid clashes

table label

<ebruchez> (following the IRC logs, but going to lunch now)

John: So can the UI get to the inner model or not?

Charlie: I thought of it as a blackbox, and so thought that was useful
... but I understand there may be more usecases, so maybe we should allow it
... I like the idea of keeping it simple

Mark: WIth your idea of showing the list of places you can get to from Dallas would require access to the inner model

Charlie: That would be a sibling instance

[meeting breaks into small group discussions]

<unl> Uli: I'd like to question model nesting generally. Encapsulation can be achieved in other, better understood ways (inheritance).

Mark: @ref on everything

John: How does it know to use that value?

Mark: Well, all elements should conceptually have a ::value which is afected by events that cause it to update

John: Are you interested in co-writing the message module?

Mark: Yes

John: I would like to participate

Mark: We should do it wiki style

Steven: I have long thought about a wiki that produces W3C specs

Many: Yes!

<unl> Or we have an XForms app for writing specs

<wellsk> Scribe: wellsk

John: looking for volunteers for modules

Charlie: excited about Generalizing Constraints beyond the UI

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

John: Organized modules last night
... parallel efforts in module work

Nick: ease-of-authoring, and later do some

John: Nick has some for formal 1.2

Nick: easy to attach on wiki

John: mentions email about child elements of bind
... wiki is good for placeholder and prioritizing
... data properties and instance modules could lead to submission module
... Steve, move himself off message module and Stevenn to work with Mark
... asking Steven to take on label module
... is label module big enough to care about? Is it worthwhile doing one?

Steven: mostly harmless, if need it they can use it

John: question to Doug - does svg have way to attach labels.

Doug: no, talking about best practices for labels

<klotz> i only found out recently that CSS2.1 removed caption-side left and right, which is how we were going to style labels in CSS

Doug: talking about associating text with graphic
... establish semantic relationship between

John: use bind to do that

Doug: or RDF Rdf-like for relationship
... show me this block, this hint, showing on graph is ueseful

John: press F1 what happens..

Doug: block of things with title, refer to group as block of things

John: anybody interested in instance data module

Uli: raises hand -- is volunteering

Nick: having modules for 2.0?

John: Uli/Charlie violunteering for data properties module?

Charlie: no

Uli: yes

John: model/validation/actions -- leave untasked for now?
... half hour left
... look at other 1.2 possible features? Perhaps review them now
... some may go away, some pertinent some not
... 1.2 Possible area

http://www.w3.org/MarkUp/Forms/wiki/XForms_Future_Features

John: query: "Specific actions instead of general insert" moved to possible features after ...
... what are ways people are using things together?
... higher level markup
... for 1.2, more latitude for different markup other than simplified actions
... Specific actions instead of general insert moved out of the way
... next is "Value attribute on send action "

Nick: attributes for submission to override ones in submission?

John: to vary the submission
... send and as child, conflicts

Nick: place where we refer dynamically to ids?

John: toggle and <scribe missed rest>

Uli: want more dynamic use dispatch

John: delete "Value attribute on send action "; goes away
... " Need ability to conditionally cancel events "
... does this go away too
... XML Events 2 solves this
... place this for 2.0 and solve by bringing in XML Events 2

Nick: in theory, you can refer to XE 2

John: XForms 2.0 where we do upgrades
... on "Better DOM interface to expose all actions "

Nick: depends on how far we get to modularization, interested in pursuing

John: Nick and Uli volunteer

<John_Boyer> ACTION: Charlie, Uli and John to write instance module [recorded in http://www.w3.org/2008/02/06-forms-minutes.html#action02]

<trackbot-ng> Sorry, couldn't find user - Charlie,

<scribe> ACTION: Mark Birbeck and Steven to work on Modularization: Message Module [recorded in http://www.w3.org/2008/02/06-forms-minutes.html#action03]

<trackbot-ng> Sorry, amibiguous username (more than one match) - Mark

<trackbot-ng> Try using a different identifier, such as family name or username (eg. mseaborn, mbirbeck)

<John_Boyer> ACTION: Uli and John to write data properties module [recorded in http://www.w3.org/2008/02/06-forms-minutes.html#action04]

<trackbot-ng> Sorry, couldn't find user - Uli

<scribe> ACTION: Uli and Nick on "Better DOM interface to expose all actions " [recorded in http://www.w3.org/2008/02/06-forms-minutes.html#action05]

<trackbot-ng> Sorry, couldn't find user - Uli

John: on "Recoverable link error on instance src "
... make link exception cancelable?
... or make an exception or error

Nick: what about canceling exception

John: editorial changes, find exceptions, then add words to effect of "the default processing is to halt processing"

Steven: if you want to do this, do a submission instead of a src?

John: if instance is empty, lazy authoring takes over and creates instance anyways

John+Nick: achieved thru different means

John: do we really need this?

Nick: inconsistent behavior with new lazy authoring

John: Nick's arguments win -- let's shoot this one

Leigh: remain interested, not there yet for concrete proposal for WAF WG

close to adjournment

call next week

trackbot-ng, end meeting

- DRAFT -

Forms Working Group Teleconference

06 Feb 2008

Attendees

Contents

Agenda Review

Custom Functions

Optional Model

Optional model (continued)

Nested Models

Summary of Action Items

Scribe.perl diagnostic output