See also: IRC log
<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
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.
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
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
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/Uli/Nick/ Succeeded: s/Uli/Erik/ FAILED: s/L$// Succeeded: s/src attribute on model/src attribute/ Succeeded: s/submision/submission some day/ Succeeded: s/t?L/t?/ Succeeded: s/THe/The/ FAILED: s/Topic: rechartering/Topic: Rechartering/ Found Scribe: Leigh Found ScribeNick: klotz Found ScribeNick: klotz Found Scribe: klotz Inferring ScribeNick: klotz Found Scribe: Nick Found ScribeNick: nvdbleek Scribes: Leigh, klotz, Nick ScribeNicks: klotz, nvdbleek Default Present: Leigh_Klotz, wiecha Present: Nick Erik Uli John Leigh Steven Regrets: Charlie Steven_(morning) Agenda: http://www.w3.org/MarkUp/Forms/wiki/FtF_2009_11_Palo_Alto_Agenda Found Date: 05 Nov 2009 Guessing minutes URL: http://www.w3.org/2009/11/05-forms-minutes.html People with action items: charlie WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]