Forms WG Face to Face Meeting Nov. 5, 2009 -- 05 Nov 2009

<John_Boyer> scribe: Leigh

<John_Boyer> scribenick: klotz

<Steven> trackbot, start telecon

<trackbot> Meeting: Forms Working Group Teleconference

<trackbot> Date: 05 November 2009

<John_Boyer> Charlie is not able to join today, so we hung up on zakim

<John_Boyer> it raises the point that there are things we ask of zakim that we should be able to ask of trackbot instead

<John_Boyer> like who is here

<scribe> scribenick: klotz

<scribe> scribe: klotz

rechartering

John: Phillipe reported that we had a good turnout for XForms 1.1 AC vote
... In 2007, TBL and Steve Bratt asked me to look at broadening adoption of XForms on the web.
... Our conclusion was that we needed an indirect means to get it implemented in browsers, and so we started Ubiquity.

Erik: ..

John: The Dojo-style approach seems to work for the W3C management.
... We need to ask for rechartering by the end of this month, with a vote in January.

Uli: I understand your concerns, Erik. But I'd like to have a showcase at the W3C site.

Leigh: Someone would have to make a usable release of Ubiquity; the focus so far has been on test coverage demonstration.

John: It's work.

Erik: I have no objection to showing a javascript version for the W3C website. But if the view is that it's competition with HTML5, it won't be positive.

John: I don't think that W3C has decided that XML doesn't belong on the web. We live in the complicated app space.

<John_Boyer> Perhaps I should say "sophisticated" app space

Nick: view source is useful

John: The technical press people wanted to see view source for html5.

Erik: On the back end, we're integrated with XQuery, XPath, XML Schema, XML, the whole W3C XML stack

John: XForms is an end-to-end XML application technology, not necessarily something for the HTML group. Our new charter needs to show that.
... So should we be doing XForms for HTML? Maybe not?

Erik: I hope not. Last time that was put in the charter, but nobody seemed to want to finish the work.

John: In this case, unlike 2007, we are being asked to propose our charter.

Leigh: So maybe we can find a home for the extension work outside and do the core work?

John: There's a lot of core work.

Erik: ...

John: The work on top of 1.1 is simpler.

Nick: Some features are, but others aren't. XPath 2.0 and dialog are weeks or months.

John: Of individuals doing smaller specs. And we attempt to publish those as separate specs, with separate smaller test suites.
... We don't have to test XPath in every location, just show it works and use the nodeset 1.0 terminology. One calculate, one ui binding, maybe a dozen or two tests.

Erik: XForms 1.1 is a more solid platform and XForms 1.0 was mostly implemented.
... So how do we keep members and not drop members?
... How do we lower the barrier to entry, as Raman said?
... Maybe more observers

Leigh: Observers haven't agreed to the patent policy.

John: Maybe we need an XForms extensions group somewhere.
... W3C and IETF have coordinated.

Nick: We don't want to lose resources.

Erik: Rechartering the group is a great thing to do but we need concrete steps on members.

John: We could do more sharing phone calls with extension groups.
... The www-forms list has many members who could contribute.

Erik: The membership policy is my issue.

John: Vocal technical leaders on some web projects aren't part of large organizations. It's hard to get people like that in large companies.

Erik: So, the question isn't resolved.

John: Issue #1 is that W3C recharterng seems like it would be encouraged.e
... #2 our charter should be about XML applications on the web.
... Phillipe did a multi-namespaced app and they wanted to see the svg namespace in use.
... For an extensions group, we'd need to address the patent policy.

Leigh: Setting up a pied-a-terre would be useful.

John: I've been asked to do our charter request by the end of November.

Leigh: This would be for things like extension libraries for non W3C type things, financial libraries.
... I.,e. for folks who don't share the W3C web view, but are interested in ODF, e-commerce, business process, etc.

John: So we should apply for rechartering in W3C?

Uli: Yes. Great.

<Steven> I have a draft charter, but with no real technical content

Steven, we'd like to up the focus on the things we really do well: XML end-to-end.

Uli: TPAC discussion yesterday on namespace dependencies.
... Extensibility

John: The W3C used URLs for namespaces to decentralize it for XML.

Nick: They discussed prohibiting any extensions to HTML unless you write a spec.
... Microsoft said it worked and Mozilla asked for a registry.

Uli: They said use a Wiki for a registry. Nobody wants a central registry for namespaces.
... I don't think it's a requirement that namespaces be beautiful.

John: Noah Mendelssohn said that the default case was problematic because of cut and paste.

Erik: Yes.
... It's more for XSLT transformers; you need to do the namespace fixup.
... As a user you hit the default namespace problem mostly.

Nick: Everybody uses namespaces in JavaScript already. They're the same programmers.

Uli: I don't buy the argument that the indirection is a problem. It's a political issue because it comes from XML.
... They didn't want to talk about the syntax.

John: I didn't get the idea that namespaces support would be available for HTML files in from Microsoft.

Nick: They're in the HTML namespace in the DOM.
... They changed Firefox so that they're in the HTML namespace.

Erik: So you can do it in an XML serialization.

Nick: You use svg:

Uli: Not in the HTML seriailization. There's hardcoded mappings once you hit the svg element.

Erik: You can produce XHTML5.

John: The browser will not choose the right parser to use if you set the wrong content type.

Erik: So why not set the content type?

Uli: The biggest browsers don't support it.

Erik: Nor do they support svg.

Nick: But all elements in the DOM are in the XHTML namespace.

Erik: If you're using XHTML5, IE6 doesn't matter.
... Isn't that their position: use the XML serialization.

Uli: They assume nobody will use it. IE8 doesn't support application/xml+xhtml. You only get it if the document is served up with that type.

Erik: IE8 doesn't support SVG or canvas either.
... We author in XHTML and then let Michael Kay serialize it to HTML for us.

Custom functions

John: Erik, do you have feedback from Michael Kay on functions?

Erik: I proposed value-of and sequence instead of result, but Michael suggested we not use value-of because it produces a text-node not a string.
... He suggested keeping only sequence. He said they had a result element but switched to sequence.
... So result is clearer, but XSLT doesn't have one. So we can use the closer syntax or something more proper for xforms.

Nick: Will we support sequence constructors?

Erik: It would be result/@select. If you have variables you can construct anything you want.
... So I would be inclined to remove value-of, but I don't know about result vs sequence.

John: result would have the single result semantic.

Nick: Multiple result elements?

Erik: No.

Uli: I would prefer result overs sequence if we support XPath 1.0 but I'm not sure of that. I think we should first look at XPath 2.0 and backport.

John: It's already clear how to make it work.
... If you could have multiple sequence elements, can you have var/var/seq/var/var/seq?

Erik: Yes.
... It constructs the sequence.

Nick: And in XSLT you can add XML markup.

John: For XPath 1.0 how do we construct the answer?
... If the sequences are different types it would be an error.

Leigh: Or coerce them all to string.

John: Yes, downgrade the behavior.

Erik: It's a corner case for xpath 1.0.
... That's one piece of feedback.
... The other issue was initial context being empty. He said it as for simplicity: XSLT has no live instances, all global functions, one initial document. So no need.
... For XSLT 2.1 they are planning first-class and higher-order functions.

John: What is the context?

s/L$//

Leigh: Are they closures?

John: If we decide to set the context where the function is declared does that later break?

Leigh: No, it would be consistent with closures.

Erik: They might want to change initial context in the future. They will have anonymous functions, nested.
... But they didn't say what.

John: Will you have trouble with initial context in an OTS XPath engine?

Erik: I think not. But I did mention it to Michael Kay.

Leigh: As you pointed out your function library can hold the function,context tuple itself.

Erik: He's working on local variable scoping.
... I think you can implement it yourself with your own functions, even.

John: So it seems forward compatible with the way the wind is blowing.

Erik: I told him I would like it,.

Leigh: Maybe we should tell them we would like it.

Nick: An interpreter may have less performance

Erik: Yes, it can be optimized more.
... They also said they hadn't dicsussed named local functions yet.

Leigh: Just read http://mitpress.mit.edu/sicp/
... We should lobby them for closures.

Erik: We won't get that until 2.1. But it's doable and they're working.

Uli: There's a bigger movement to HOF.

Erik: They will have higher-order functions and inline nested functions.

Leigh: I think we should write it up as a formal comments.

John: Leigh?

Leigh: As long as Erik sends me a note saying what we've already agreed to.

John: So sequence, not result, for custom functions.

<John_Boyer> scribe: Nick

<John_Boyer> scribenick: nvdbleek

External model

John: To recall we will have a simple src attribute, and an import element to sidestep the sub-model problem
... What is the difference between an include and import element?

ebruchez: An import element would have more semantic then an include element

John_Boyer: We only support the import element as a direct child of model
... this solves Stevens simple use cases
... and you can use import to import the contents of multiple model elements
... The import doesn't solves the duplicate id problem

klotz: Yes it will include the contents and add the functions of the function attribute and the same for the schema attribute

ebruchez: You don't have to create a single infoset that contains the resolved imports

klotz: this is something that should be noted in the spec

<John_Boyer> and if the imported model contained an inline schema, an xforms-ready handler, a submission or an instance, or any multiples of those, the processor behaves as if those had been written into the importing model

<John_Boyer> Leigh: It wouldn't be possible to schema validate the XForms document

klotz: we need to remove the idref'nes from bind

<John_Boyer> This affects bind attribute on inputs, submission on send, etc.

John_Boyer: Do we resolve that this will work for now?

(consensus in the group, we can live with this proposal)

John_Boyer: This is a first step of moving away from id's
... the imports should be resolved at model-construct

nvdbleek: if we have imports for the UI then they should be resolved when the UI is created, then you can have dynamic imports

klotz: we could have AVT's on them

<John_Boyer> Uli: (above) why not have import for UI too?

klotz: We should have an import with a relevance to conditional show UI content

ebruchez: Didn't Mark sugest this to Joern doing this with a load that replaces inline content

klotz: it was show="embed"

<John_Boyer> could be show="#someID"

klotz: target-id was already on load

<klotz> http://lists.w3.org/Archives/Public/www-forms/2009Jun/0022.html is the proposal from Joern Turner.

nvdbleek: we should do import in UI later, bcz. it looks like in the UI you want it to be more dynamic

John_Boyer: or do it with submission, and there is already a feature of synchronizing load and submission

ebruchez: It wouldn't hurt to have also a simple import mechanism with import

<unl> unl: load and instance/@src should be defined in terms of submission some day

John_Boyer: we need to think about it more what about groups and repeats

klotz: static UI content inclusion should be a host language feature

John_Boyer: we will do import in model only, and also support src on model
... if an imported model contains an import that will be resolved (it is an error if a cycle is detected)

klotz: For the UI we need to concentrate on dynamic import for UI

wiecha: if we have dynamic UI we will need dynamic model inclusion for the binds of the UI

unl: when the UI needs a new model that sounds like components

ebruchez: we have proposal on our wiki for models everywhere even inside a repeat
... the models would be scoped

unl: that are simplified components

ebruchez: yes it is, a lightway approach for simple components

<ebruchez> http://wiki.orbeon.com/forms/projects/xforms-model-scoping-rules

klotz: is it consistant with your xbl work?

ebruchez: yes it is

wiecha: do you allows binds between those models

ebruchez: TBD

John_Boyer: what is a use case for submodels that get replaced/injected into a model

wiecha: for incrementaly building a form
... the new 'parts' will add to the model and will bind to the 'parent' model

nvdbleek: We don't need dynamic model import if we don't have dynamic UI import, lets postpone it till then

<John_Boyer> import with src for model-only content resolved once during model-construct with error on cyclic import

<John_Boyer> also resource attribute as alternative to src

John_Boyer: We need to do something about foreign namespaced attributes

nvdbleek: we can't do this because we don't know how to combine duplicate

klotz: we don't need to specify it, it is the extension mechanism of the implementation that needs to give access to all the foreign namespace attributes and children

<John_Boyer> John_Boyer: I'm only trying resolve a seeming inconsistency between having foreign namespaced elements in an imported model being put into the importing model but not having foreign namespaced attributes on the imported model being copied over in some way

<John_Boyer> Leigh: We should be very specific about what content is copied over.

<John_Boyer> Leigh: Limit it to copying exactly inline schema, bind, action, instance, submission, then specify by a NOTE that future extension modules should specify how they participate in model imports

<John_Boyer> John_Boyer: That works for me

RESOLUTION: import with src/resource for model-only content resolved once during model-construct with error on cyclic import as a direct child of model

<scribe> ACTION: Charlie to write the module for 'import with src/resource for model-only content resolved once during model-construct with error on cyclic import as a direct child of model' [recorded in http://www.w3.org/2009/11/05-forms-minutes.html#action01]

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

<John_Boyer> steven arrives to meeting

<Steven> s/Topic: rechartering/Topic: Rechartering

- DRAFT -

Forms WG Face to Face Meeting Nov. 5, 2009

05 Nov 2009

Attendees

Contents

rechartering

Custom functions

External model

Summary of Action Items

Scribe.perl diagnostic output