IRC log of forms on 2008-06-11

Timestamps are in UTC.

06:58:50 [RRSAgent]
RRSAgent has joined #forms
06:58:50 [RRSAgent]
logging to
06:59:21 [John_Boyer]
rrsagent, make log public
07:02:16 [wellsk]
wellsk has joined #forms
07:09:50 [klotz]
klotz has joined #forms
07:10:00 [ebruchez]
ebruchez has joined #forms
07:19:20 [Roger]
Roger has joined #forms
07:19:30 [Charlie]
Charlie has joined #forms
07:19:30 [klotz]
scribenick: klotz
07:20:13 [unl]
unl has joined #forms
07:20:13 [Rafael]
Rafael has joined #forms
07:20:35 [klotz]
topic: Streamlined Syntax
07:20:42 [Steven]
Steven has joined #forms
07:20:57 [klotz]
john: we've talked about an xforms aggregator module, really XForms Full Aggregator Module, and a Model Only.
07:21:14 [Steven]
rrsagent, make minutes
07:21:14 [RRSAgent]
I have made the request to generate Steven
07:21:17 [klotz]
john: then a streamlined module, which adds all the additional attributes to ui controls.
07:21:42 [klotz]
john: does that seem like the right approach? add @relevant to input.
07:21:53 [klotz]
charlie: xf:input or html:input? that may imply a different driver, right?
07:22:13 [klotz]
charlie: it just occurs to me that i don't really recall where we had anticipated them going last month
07:22:20 [klotz]
john: i don't see why they can't go on our elements
07:22:27 [klotz]
charlie: as a streamlined syntax, it's one of our options
07:22:40 [klotz]
john: do we put all those attributes on our elements?
07:22:59 [klotz]
steven: we still have to discuss and resolve whether it's ok for us to import xforms wholesale into xhtml2
07:23:05 [klotz]
john: without namespaces
07:23:14 [klotz]
charlie: there are two uses, for ourselves, and as an onramp
07:23:41 [klotz]
leigh: i think xslt as a way to do it
07:24:22 [klotz]
erik: so what about namespaces? i see people using prefixes now. i don't necessarily agree, but if you want to inject stuff into an html serialization it make some sense. i don't disagree with a language having multiple serializations.
07:25:25 [klotz]
charlie: so we'd be less "religious" about the mechanics of how the concepts are injected into other applications if you implement the semantics. none of this takes away a need for a driver.
07:25:49 [klotz]
leigh: that's why i said that a description, prose or xslt, would be a fine way to describe the mapping of html+extra into xforms
07:26:04 [klotz]
john: so that module gives something for the transformation to aim at
07:26:41 [klotz]
john: we should have a talk about Nick's changes so we can look at them and see if they go into the streamlined syntax module and which go into core submission and core ui control
07:26:48 [klotz]
nick: it's not a lot of adjustments i've made
07:29:20 [klotz]
nick: [projects changes]
07:31:24 [klotz]
nick: i've created two new subsections, common submission attributes for submit and send (same table as before) and common submission child elements
07:31:54 [klotz]
leigh: is there a confusion between ref on submission and ref on submit
07:32:00 [klotz]
john: there is a difference
07:32:10 [klotz]
leigh: they're now defined in the same spot
07:32:20 [klotz]
steven: we use ref on submit
07:33:00 [klotz]
john: but it's a ui binding on submit and not on submission; you also have model attribute. do we now need model on submission? are we putting submission outside a model?
07:33:34 [klotz]
nick: no submission is still in model; i've made the resource optional and the submission element is still in the same place, with common attributes, but I need to redo it because of ref
07:33:37 [klotz]
leigh: and bind
07:33:56 [klotz]
john: it will combine with ref on submit; submit has ref/bind/model; submission doesn't have the model attribute.
07:33:57 [Steven]
Yesterday's minutes now in place at
07:34:02 [klotz]
nick: model wasn't in this list.
07:34:12 [klotz]
nick: then you can't override what is submitted.
07:34:20 [klotz]
charlie: so you use these on the submit element?
07:34:37 [klotz]
charlie: then put submission as child of submit; it will look a little weird but it will be clear
07:35:06 [klotz]
nick: i wrote that local submission elements override the referred submission so you can specify the resource locally.
07:36:24 [klotz]
leigh: so if we had a child submission element it would take precedence in its attributes over the id-referenced submission
07:36:30 [klotz]
charlie: or only its attributes if there is no reference
07:37:31 [klotz]
erik: I see, so you can bind the trigger to another node to control relevance and we'd lose that.
07:37:47 [klotz]
john: why isn't it backwards compatible?
07:37:50 [klotz]
nick: ...
07:38:01 [klotz]
john: you can still do it by using a full submission element.
07:38:29 [klotz]
erik: it has a different behavior for existing code: submit/@ref now implies the data to submit
07:39:30 [klotz]
uli: wouldn't it be much easier to include a child element of submission on submit
07:40:16 [klotz]
charlie: it's not clear where the events get dispatched, to the local submission or the model one; it's clearer when you put hte attributes on submit
07:40:30 [klotz]
erik: what was the initial goal for overriding attributes on the submit button?
07:40:48 [klotz]
nick: it was for streamlined syntax so you don't have to have a submission in the model
07:41:11 [Steven]
Meeting: Forms FtF, Amsterdam, Day 3
07:41:24 [klotz]
nick: it also allows you to change the src attribute in the submission for different submit controls
07:41:28 [Steven]
Chair: John
07:41:29 [klotz]
07:41:46 [klotz]
erik: so this is for no model, no submission, all ui?
07:42:07 [Steven]
Present: Charlie, John, Erik, Leigh, Nick, Rogelio, Rafael, Steven
07:42:15 [klotz]
john: i think we can just say ref doesn't override. then it's time to write a submission element.
07:42:23 [Steven]
Regrets: MarkS
07:42:26 [klotz]
charlie: i'm a little worried about special-casing it.
07:42:28 [Steven]
rrsagent, make minutes
07:42:28 [RRSAgent]
I have made the request to generate Steven
07:43:10 [klotz]
erik: the nested element solution isn't good for simple syntax
07:43:24 [Steven]
07:43:36 [klotz]
john: this has to boil back down to input type="submit" with a couple of other attributes. ref isn't even going to be one of htem.
07:43:50 [klotz]
nick: are we making this change to submit or input?
07:43:54 [Steven]
07:44:12 [klotz]
john: it will happen from streamlined syntax
07:44:12 [klotz]
erik: but we don't have input type="submit"
07:44:31 [Steven]
rrsagent, make minutes
07:44:31 [RRSAgent]
I have made the request to generate Steven
07:45:08 [klotz]
erik: xslt can produce a submission attribute
07:45:14 [Steven]
07:45:23 [klotz]
nick: the sourceforge converter I posted does this, with modes in xslt
07:45:35 [Steven]
rrsagent, make minutes
07:45:35 [RRSAgent]
I have made the request to generate Steven
07:46:29 [klotz]
john: so it should be possible to write the html or xhtml module for xforms to do this
07:46:52 [klotz]
erik: so input type="submit" is equivalent
07:48:57 [klotz]
leigh: if this is for hte onramp it should be doable with an xslt or a javascript library; for xhtm2 a module is fine
07:49:11 [Steven]
07:49:14 [klotz]
erik: so what is the next step for an existing html form? input type="submit". so what's t next step
07:49:56 [klotz]
john: that implies that we should have an input type="submit" that maps on to submission
07:50:49 [klotz]
leigh: we can define our own input type="submit"
07:55:34 [klotz]
leigh: but who would use it? i can understand an xslt that maps html4 input type="submit"
07:56:09 [klotz]
leigh: i can understand a module of xforms core additional support for the output of that transformation
07:56:39 [klotz]
leigh: but i can't understand a module that adds xf:input type="submit" to xforms; who would use it?
07:58:23 [klotz]
charlie: but we want a streamlined syntax for our xforms authors
07:58:48 [klotz]
steven: is it a moment of simplification and a lifetime of grief?
07:59:53 [Steven]
I don't see what it simplifies; MVC gives you long-term simflification
08:00:19 [Steven]
I see streamlines syntax as adding the font tag back into xhtml to help people us stylesheets!
08:00:24 [Steven]
08:00:33 [Steven]
s/us /use /
08:01:36 [klotz]
leigh: i think it's fine to have an html4 syntax library in javascript and an xslt or prose transformation to core xforms, but i don't see that the html4 syntax with javascript is the exact same sequence of characters that should appear in an xforms simplified syntax
08:01:48 [klotz]
uli: is this xml?
08:02:30 [klotz]
john: xml well-formedness is an illusion. they can use the same tags and attributes. they shouldn't have to throw out tag names and switch to xml and give up on attributes.
08:09:29 [klotz]
leigh: i can see the value of the xslt to convert html+stuff into xforms, and the value of a JS implementation of hte same, but no value in an XForms module that adds the exact same attributes to XForms
08:09:46 [klotz]
charlie: but we want a simplified syntax
08:10:14 [nick]
08:10:16 [klotz]
leigh: yes, that's great, but it's not necessarily the same syntax as the additions to html4.
08:11:31 [klotz]
leigh: so I think there should be an XSLT or XSLT-in-prose for converting HTML4+attributes into canonical XForms, and a module that adds any necessary support for that, and an OSS JS library that for some high percentage of cases works the same in HTML4 browsers, and the XSLT could be a W3C note or even a non-W3C Note, but it's not a module of XForms
08:11:45 [klotz]
leigh: Mark Birbeck and Paul Butcher arrive
08:16:26 [Steven]
08:17:09 [Steven]
08:17:18 [Steven]
rrsagent, make minutes
08:17:18 [RRSAgent]
I have made the request to generate Steven
08:21:23 [markbirbeck]
markbirbeck has joined #forms
08:23:43 [markbirbeck]
Hey Keith. Are you managing to stay awake?
08:23:58 [markbirbeck]
08:37:03 [klotz]
mark: I think we should have a legacy module, as in XHTML2, to fully describe the HTML4 forms and it would be optional to implement, but it's an important part of the onramp. An XSLT wrapping isn't the same.
08:37:10 [klotz]
Erik: The DOM is different for example
08:37:52 [klotz]
Nick: There are some HTML4 attributes that are hard to implement.
08:38:31 [klotz]
leigh: I had thought we were going to implement features necessary to transform HTML4 into canonical XForms but just not maintain the HTML4 syntax as a spec.
08:38:42 [klotz]
paul: What attributes are hard to implement?
08:38:50 [klotz]
Erik: I see more of a jump than a progressive ramping up
08:39:28 [klotz]
mark: We've been doing those kinds of things...nobody's produced the finished example yet, but there's been discussion about those kinds of iterative steps
08:39:58 [klotz]
Erik: maybe it's my fault but I don't have it in mind. i think this discussion started with Nick's work on xf:submit and I didn't see how this helped us
08:40:46 [klotz]
Mark: This i old ground...we agreed there are two sides: now HTML form processing (model, logic, lifecycle, events) maps to XForms, and then if there are features in XForms that need tweaking to accommodate the symmetry.
08:41:21 [klotz]
Erik: But the submission can be done with a submission and a submit both, since it turns out we really want input type="submit"
08:41:55 [klotz]
John: I don't want gratuitous differences between submit and input type="submit" so we should add them to both. There are certainly differences between core xforms and streamlined syntax.
08:42:53 [klotz]
John: For the simplification of core xforms tasks, unless there's a good reason to deviate, we should make an effort to make it look the same in both xforms simplified syntax and html4.
08:43:11 [klotz]
Leigh: I don't agree iwth the goal but 40% of example can convince me.
08:43:14 [klotz]
08:45:11 [klotz]
Mark: You have to have quite a bit of stuff on the plate to get, for example, a range in a form, then you need to know a lot of stuff.
08:48:10 [klotz]
Leigh: That's the core Canonicalization problem.
08:49:26 [klotz]
Leigh: But the question is whether the xforms simplification and the html4 complification result in the same language; I don't think so, but it's fine for John to want us to go that way for to keep trying for it as a goal, but I think it's a something has to be shown.
08:49:35 [klotz]
Erik: ...
08:49:36 [klotz]
Nick: ..
08:49:38 [klotz]
Leigh: ...
08:50:11 [klotz]
Mark: We're aiming at unobtrusive JavaScript, not arbitrary stuff. We're in the same space and direction and world view as these libraries. We're saying we should attach a particular type of model to this.
08:50:38 [klotz]
Nick: So the goal of ubiquity is an existing html form with all the javascript working? don't you have DOM problems?
08:51:34 [klotz]
Mark: In the modern libraries, it doesn't use the form submission; they use XHR. So they've already marshalled the normal flow. I can say that I can give you an event to start submission and some of them are doing this. We follow the specification for the specification.
08:51:57 [klotz]
Erik: But you're talking about how to implement ubiquity
08:52:39 [klotz]
John: We started this with a discussion of submission attributes on submit and that didn't work because of @ref. Then we talked about adding submission as a child element of submit, but I said that simplification looks different and isn't tag-parallel with input type="submit"
08:53:16 [klotz]
John: So when we do XForms simplifications that aren't going to match HTML complifications, how seriously do we take that problem? That's all we have to resolve here.
08:53:35 [klotz]
Uli: For me the main point is to simplify the syntax without a model, as Mark said. Bt I'm not concerned about HTML4.
09:02:47 [klotz]
Charlie: That's what gets us where we are. But my main concern about Leigh's two tracks is that unless we actively grow it, are we ...
09:02:49 [klotz]
Mark: ...
09:02:53 [klotz]
Leigh: ...
09:03:25 [klotz]
Paul: I'd like to ask about ref on submit and submission. If you're calling submit with these shorthand submission attributes, you're not going to lose behavior on submit by binding it to a particular node.
09:03:59 [klotz]
Nick: The attributes that are local override the submission. In XForms 1.0 or 1.1 you can already have a ref attribute on submit for relevance, so in 1.2 that will override the submission ref.
09:04:05 [klotz]
Paul: OK
09:04:25 [klotz]
Erik: One solution was to say that ref and bind are not overridden; that's possible from a spec level but it doesn't work for authors.
09:04:43 [klotz]
Mark: What's the driving force for the abbreviated syntax?
09:04:47 [klotz]
Leigh: My question exactly
09:05:09 [klotz]
Charlie: It's not a simplification for the onramp. It's a good example of simplification for XForms that's misaligned with the "complification" track.
09:06:03 [klotz]
Mark: We already have a potential child element, send, and the attributes could go there.
09:06:09 [klotz]
Charlie: That also solves the event dispatch problem
09:06:23 [klotz]
John: How does it simplify anything?
09:07:01 [klotz]
Mark: I don't care too much about it anyway as I'm concerned on the HTML transformation
09:07:11 [klotz]
Erik: submit is simplified syntax for trigger+send
09:07:15 [klotz]
Mark: So why complicate it?
09:07:25 [klotz]
John: Because it doesn't have a submission element.
09:07:30 [klotz]
Mark: So what's wrong?
09:08:00 [klotz]
John: I'd rather attack it in the reverse direction. What do we want input type="submit" to look like? Then how do we write that without a submission?
09:08:32 [klotz]
John: Do we need to make cdata-section-elements on submit? Really we only want 2 or 3 on input type="submit" and put those on submit and be done.
09:08:59 [klotz]
Erik: We tried that with the form element. So input type="submit" is all we need.
09:09:28 [klotz]
John: People know stuff about HTML forms today; they want to evolve their capabilities and add it one at a time via attributes
09:09:30 [klotz]
Uli: via javascript libraries
09:10:11 [klotz]
Mark: Dojo could add that feature, an xforms attribute in an unobtrusive javascript library on form. So it's an ideal gradual onramp to add attributes to the form element.
09:10:25 [klotz]
Nick: Nobody uses the action attribute on a form anyway; everybody uses javascript
09:10:52 [klotz]
Mark: You put it in the form action and the javascript does extra clever stuff.
09:11:29 [klotz]
Steven: But don't unknown attributes disappear from the dom in HTML5?
09:11:42 [klotz]
Steven: So doesn't that break adding attributes processed via Javascript?
09:11:48 [klotz]
* Break
09:16:57 [klotz]
Charlie: I quite like this idea of a deprecated chapter.
09:17:09 [klotz]
John: What's the difference between a chapter and another module?
09:17:52 [klotz]
Uli: I thought the idea of modules, for message, for example, does it start an xforms processor?
09:18:11 [klotz]
John: It causes a set of markup to begin working in an implementation specific way.
09:18:49 [klotz]
John: It's not done until we agree it's done...similar to the IDL discussion we had.
09:20:14 [klotz]
John: To control the one submission, it's ok but the submit element lets you say you have more than one.
09:20:21 [klotz]
Erik: Then you create a submission.
09:21:10 [klotz]
John: I'm not necessarily against it. The form element
09:24:41 [klotz]
Leigh: Aren't we automating hte past? We heard from Nick and Mark that people are not doing a lot of work using form/@action but the libraries in Javascript instead, and the behaviors emerging from that may be a better target.
09:35:09 [klotz]
Erik: I see the power of XForms as a way to make bigger forms, not for small form authors.
09:35:10 [klotz]
09:35:33 [klotz]
Leigh: I don't see the attributes added to HTML4 necessary to add to core XForms.
09:35:57 [klotz]
Mark: How about an XHTML1.1 module of attributes from XForms?
09:36:16 [klotz]
Charlie: That's what we're proposing but a twist, an XHTML1.1 module, not an XForms module.
09:36:26 [klotz]
leigh: it's a key difference, not a twist.
09:37:53 [klotz]
Charlie: Then we get 40% of the way, as Leigh says, and step back and see if we want to incorporate some of that back into XForms, but that document is a formal work product for us for our charter.
09:41:40 [klotz]
Mark: My proposal was to have a series of modules for XHTML11, not just one module. One for submission attributes, one for message, etc.
09:43:02 [klotz]
Erik: Should we be using the webforms attribute names?
09:43:48 [klotz]
Mark: If they make sense, but the issue is there is an underlying model and MVC and dependency graph in XForms and webforms has this work with events and elements talking to each other.
09:44:06 [klotz]
Charlie: So can we agree to produce the XHTML modules?
09:44:13 [klotz]
Nick: We agreed in Raleigh.
09:44:18 [klotz]
Charlie: That was modules for XForms.
09:44:31 [klotz]
Nick: There is still work, which Mark did, but no concrete module.
09:44:38 [klotz]
John: There is the syntax example for PO.
09:44:51 [klotz]
John: Now we have more clarity and can turn that into a module.
09:45:16 [klotz]
Mark: Sticking with something smaller, submission attributes and message. name and others bring more stuff. Just get one module out, a smaller one.
09:45:52 [klotz]
John: We spent a fair bit of time yesterday...we went through the submission attributes. Some were associated with submission, and some were validity, data, etc modules.
09:46:04 [klotz]
John: So you could have submission without data.
09:46:13 [klotz]
Charlie: We have that yesterday.
09:47:01 [klotz]
Mark: So that would be perfect for XHTML.
09:47:01 [klotz]
Mark: We could have an XHTML modularization module with several attributes, no ref.
09:47:02 [klotz]
Charlie: We did that yesterday for XForms; we can use it on XHTML. Then we go on and do another one.
09:47:08 [klotz]
Mark: Not in the same module.
09:47:18 [klotz]
Charlie: Yes.
09:47:33 [klotz]
John: Does wrap up mean a rec-track document?
09:47:38 [klotz]
Leigh: Yes, that's what Mark is saying.
09:48:43 [klotz]
Mark: Role is a good example; it started with Raman and Steven, but then we added RDF, and then Shane got involved for modularization. Now they put in HTML5. tey have their own specification. So when things are small enough and nimble they're more easily adopted.
09:48:58 [Steven]
09:49:25 [klotz]
Erik: I have a question about hte XHTML module. One issue is providing the module. Another is adding hte ramping up, submission elements, repeat, model, etc. Where do we say how this is glued together?
09:49:44 [Steven]
s/ hte / the /G
09:50:05 [klotz]
Mark: If you follow xhtml modularization each spec has to say something about the glue.
09:50:59 [wellsk]
much better
09:51:01 [klotz]
Mark: So maybe we should just pick the uncontroversial attributes, the ones you did yesterday.
09:51:17 [klotz]
Charlie: We scrubbed the modelness out of it.
09:51:51 [klotz]
John: We created the map in the wiki. We'll have to start the work party to create this module, and then there's changing core xforms to be more like the map we've created.
09:52:28 [klotz]
John: Having that module fully developed would be helpful. We saw the XHTML2 modularization and bits look like what we've done in XForms spec. It would be good to have that module written here this week.
09:52:38 [klotz]
Mark: We can use the role attribute as a model.
09:52:51 [klotz]
John: Is it in SpecXML?
09:52:53 [klotz]
Steven: no.
09:53:07 [Steven]
It is in ShaneML
09:53:26 [klotz]
Erik: We have three attributes from wherever; what about xforms submission? Does that stay ? Does it get imported into HTML?
09:53:36 [klotz]
Mark: I believe so. Then it can be imported into SVG, as in the backplane.
09:54:08 [klotz]
Erik: We use terms such as driver or aggregator; it's pretty clear we're going to have that for XForms 1.2. Now we need another one for integrating.
09:54:57 [klotz]
John: For leaf nodes like role, it wasn't very hard. For submission module, there's a group of attributes and child elements that define core submission. if you want to use submission in combination with relevance, validity, or instance module, then you more modules.
09:55:55 [klotz]
John: So you need it seems a higher-level module that pulls together relevance, validity, instance and submission, and then the adds the elements. Erik points out this happens on the XHTML2 side and we can't create a half-dozen specs and see how to combine three of them without another spec.
09:56:31 [klotz]
Mark: In the HTML world it doesn't us ethe same data model (submission) . It's not obviously hierarchical. One problem is that we've used the same attribute name to do different things.
09:56:58 [klotz]
Mark: Let's say ref was used to bind to the data model. So ref on a div or span or svg doesn't matter.
09:57:13 [klotz]
Charlie: We wanted to avoid the submission module knowing about refs.
09:57:24 [klotz]
Charlie: There's a tipping point; at some point you need a place to put that logic.
09:57:57 [klotz]
Erik: That's what I had in mind for the small modules. But what about html input name? We want a flat XML document; we redefine or recast existing things.
09:58:04 [klotz]
John: Those are prose descriptions.
09:58:20 [klotz]
Erik: Then if we include this module, input name creates this data model in the background.
09:58:27 [klotz]
Mark: Submission doesn't care about its data model.
09:58:33 [klotz]
Erik: It assumes it's a data model.
09:58:42 [klotz]
Mark: It's capable of transmitting XML but it can do other things.
09:58:46 [klotz]
Erik: It's not JSON, it's XML.
09:59:04 [klotz]
Mark: We don't have a submission module, but if we did, it wouldn't start with XML. It would start with "something"
09:59:26 [klotz]
Paul: In that sort of module, where do you see relevance and validity? That's about submission?
10:00:08 [klotz]
John: This afternoon we should have the work jam where we look at the module breakdown.
10:01:22 [klotz]
Erik: It seems like a huge amount of work to make submission work with arbitrary data models. We tried that and stopped.
10:01:46 [klotz]
Mark: You want to be explicit about the values in attributes, the names of events, and where they occur, but leave open what's transmitted.
10:02:08 [klotz]
Erik: I can see ideally having that goal. Is it a goal of this group to handle json? If it's a sentence or two, that's fine.
10:02:24 [klotz]
Erik: When we looked at IDL for the data module, we found we'd have to write an XPath API and that wasn't our job.
10:03:51 [klotz]
Erik: And it's not clear that an XPath API is suitable for a JSON data model anyway.
10:03:55 [klotz]
* Lunch
10:04:10 [klotz]
s/* Lunch//
10:06:55 [klotz]
Paul: Can we consider submission and serialization as two separate modules?
10:07:28 [klotz]
Erik: Does this group need to worry about JSON and YAML and everything? In theory we could break up submission into many parts, based on the lifecycle.
10:08:22 [klotz]
Mark: I like Erik's hierarchy description. In theory there could be a markup version of javacsript submission. It's no tour submission because it doesn't do validation, etc. Erik asks if it's our place to define it, but it seems useful for ourselves.
10:08:30 [klotz]
Erik: Just the time and energy.
10:09:12 [klotz]
Erik: I just think it's a lot of effort.
10:09:18 [klotz]
Mark: It would be for adoption.
10:10:38 [klotz]
Mark: Having a markup version of XHR doesn't solve any particular problem, but it begins to chip away at non-standard languages and you get XForms in many places.
10:11:16 [klotz]
Erik: People take what is working and use it, like Dojo.
10:11:47 [klotz]
Charlie: Yes, but people with experience with things like dojo find complexity and want to look for something up a level. It's not an XForms pure play either.
10:12:14 [klotz]
Erik: XForms has complexity as well: we need dialogs, model packaging, etc. Providing submission to others doesn't solve my problems.
10:12:49 [klotz]
Charlie: People will pick up on Flex and Silverlight as pure plays, but I don't see Xforms as a viable competitor unless we have an way to get started.
10:13:32 [klotz]
Erik: XForms does well for forms. I'm not sure Silverlight and Flex are good for forms.
10:13:54 [klotz]
Mark: I'm not sure that's competition. I saw someone with their own framework for text for help, etc. All done in PHP.
10:14:52 [klotz]
Mark: He could have used less PHP and more Dojo, but then he'd have to commit. A standard language would help isolate that.
10:15:04 [klotz]
Charlie: I'm surprised to hear that rich web app pure plays are not competitors.
10:15:29 [klotz]
Mark: It's the architecture. When we've got these architectures going, we can be the onramp for silverlight.
10:16:00 [klotz]
Mark: Flex is different because it is the entire thing.
10:17:00 [klotz]
Erik: Every language is getting bigger and looking for things like namespaces. Calling a submission declaratively in Javscript doesn't solve it for me. I'd rather see help for complexity.
10:17:22 [klotz]
Mark: I agree; src for model is something I've talked about.
10:17:45 [klotz]
John: Why did you boot it out of 1.2, nested modules?
10:17:50 [klotz]
Erik: The whole 1.2 thing isn't it for me.
10:22:51 [klotz]
Leigh: It's natural that Erik would have different interests because he has immediate customer needs, and Charlie is worried about the strategic issue of adoption.
10:23:08 [klotz]
Erik: I'm concerned about all the time I see on modularization and it's not something I want to work on.
10:23:22 [klotz]
Erik: Who here wants to work on HTML compatibility?
10:23:33 [klotz]
John: I agree with Mark that we want more customers.
10:23:48 [klotz]
Erik: Maybe you're achieving this with ubiquity.
10:24:22 [klotz]
John: It's one solution proposed. There were two main complaints about xforms: browser availability and authoring ability.
10:24:27 [klotz]
Erik: Simplification is great.
10:24:50 [klotz]
John: It's a pre-sales problem.
10:28:57 [klotz]
Leigh: I think at this point in the WG life, after 10 years, we should be standardizing implementations based on implementation experience, not working forward from spec XML by committee to start with implementations. If you want a message module, make a message module implementation and show that it works and we'll write the document.
10:29:18 [klotz]
Erik: XProc is moving forward in this way.
10:30:36 [klotz]
John: We're supposed to be the next generation of web forms. We have a different problem. We have a whole bunch of implementations of web forms. All we're trying to do is tease apart the thing we have. It's like a failure of object orientation. Rather than figuring out what we're doing, we add three more variables. It seems like less of a crime every time until you suddenly end up with a class with 20,000 lines and 300 variables.
10:30:50 [klotz]
John: You spend a year and a half trying to modularize everything.
10:31:06 [klotz]
Erik: I don't have that problem. I have the problem of 10,000 line forms.
10:31:19 [klotz]
John: So you don't have modularization within the form.
10:36:21 [prb]
prb has joined #forms
10:43:02 [Steven]
prb is Paul Butcher, webBackplane
12:22:56 [wellsk]
wellsk has joined #forms
12:31:59 [Charlie]
Charlie has joined #forms
12:32:22 [klotz]
klotz has joined #forms
12:34:13 [unl]
unl has joined #forms
12:38:18 [prb]
prb has joined #forms
12:38:26 [John_Boyer]
John_Boyer has joined #forms
12:49:02 [nick]
13:14:52 [Steven]
Steven has joined #forms
13:31:28 [nick]
scribe: nick
13:32:56 [John_Boyer]
13:33:36 [nick]
Topic:Review of XML Http Request
13:33:49 [nick]
13:34:53 [nick]
MarkB: Reading the spec it looks like they are documenting the current implementations in the current Browsers (based op the MS version)
13:35:32 [nick]
MarkB: Our comments can't be 'they should add event X'
13:36:04 [nick]
MarkB: We should comment on problems that prevent us re-using the spec
13:36:46 [nick]
MarkB: They depend on HTML5 and the Window object which is a problem for us to reuse it
13:37:59 [nick]
MarkB: We should sent a positive response asking to remove the unnecessary dependencies
13:38:32 [nick]
MarkB: We should use it in future versions
13:39:15 [nick]
MarkB: They are already thinking about future versions of the spec
13:39:38 [nick]
MarkB: We should give input on it
13:40:05 [nick]
Charlie: We shouldn't have a one on one mapping if they add events, we could wrap their evenets
13:40:15 [nick]
13:41:31 [nick]
Charlie: Do you think their dependency on window or HTML5 is political
13:41:42 [nick]
MarkB: I think so
13:42:27 [nick]
MarkB: We should say it is good, but the spec should be the object itself. The instantiation should be in the spec that uses this spec
13:43:24 [nick]
Leigh: They can give an abstract spec and add a javascript binding
13:43:48 [nick]
MarkB: They depend on HTML5 because window is defined in it
13:44:41 [nick]
John: LC period is over, but the HTC gave us an extension, so we have to report soon
13:44:48 [nick]
MarkB: I can do it today
13:46:08 [nick]
ACTION: MarkB to respond by Friday 13 June with our comments for Review of XML Http Request
13:46:08 [trackbot]
Sorry, couldn't find user - MarkB
13:47:36 [nick]
John: You want to send some comments on the base URI?
13:49:33 [nick]
MarkB: Yes, the request uses the security using the domain. If we decouple it we want to be more flexible, we want to give the base URI when we create the object used for the security
13:50:28 [nick]
John: Isn't it a security problem?
13:50:45 [nick]
MarkB: It could be read-only in a browser environment?
13:51:22 [nick]
John: Do you not always have a containing document, which provides the base URI
13:51:29 [nick]
Uli: Server side javascript
13:51:33 [nick]
John: OK
13:51:47 [nick]
MarkB: In sidewinder ....
13:52:36 [nick]
MarkB: Explains how a relative URI is resolved in an XML application
13:52:51 [Steven]
rrsagent, here?
13:52:51 [RRSAgent]
13:53:46 [nick]
TOPIC: Review of XML Events 2
13:53:53 [nick]
13:54:15 [nick]
13:54:47 [nick]
Charlie: Most is editorial, the spec is overall good
13:55:43 [nick]
13:56:48 [nick]
Charlie: introduction section
13:57:35 [nick]
Charlie:The text isn't up to date with Event flow in DOM3
13:58:47 [nick]
John: The actual diagram still lets me believe that capture goes to the target, which isn't the case
13:59:11 [nick]
MarkB: XML events 2 is based on DOM 2 events
14:00:25 [nick]
... (differences between DOM 3 events and DOM 2 events, groups, hierarchy)
14:00:45 [nick]
John: The abstract states DOM level 3 events
14:01:09 [nick]
MarkB: When we wrote this DOM level 3 didn't had three phases
14:01:54 [nick]
John: DOM level 3 clearly states that capture doesn't goes to the target
14:02:42 [nick]
MarkB: There is a flag atTarget in DOM level 2 events
14:03:17 [nick]
MarkB: DOM level 3 has a notion of a third phase, this is a problem
14:04:27 [nick]
John: The target phase of DOM level 3 is bubble and atTarget in DOM level 2
14:05:23 [nick]
Charlie: Should we request an other version that is based on DOM level 2
14:05:49 [nick]
Steven: XML events is just a syntax
14:07:01 [nick]
MarkB: We should send a comment that DOM level 3 is required, DOM level 2 should be enough
14:07:58 [nick]
John: I would have hoped that events could flow between different documents without changing the phase
14:08:38 [nick]
John: At the cut point the event goes in target phase, this is a problem
14:09:04 [nick]
MarkB: This is well documented in XBL
14:10:27 [nick]
MarkB: He has the notion of forwarding, but you don't need it you can also hide it
14:10:50 [nick]
MarkB: We do this a lot with HTML events
14:11:38 [nick]
John: Is it available somewhere else then in XBL
14:11:51 [nick]
MarkB: NO, maybe it should be in XML events 2
14:11:57 [nick]
John: I think so
14:12:14 [nick]
MarkB: Add it to the comment we send
14:13:01 [nick]
Charlie: Are you allowed to listen for events in another DOM?
14:13:14 [nick]
s/DOM/DOM tree/
14:14:15 [nick]
... talking about remote handlers and remote observers
14:15:38 [nick]
Leigh: XML events just specify that it is just id, does it requires to be in the some DOM, can't we just add an extra attribute
14:16:22 [nick]
Leigh: The resolving can be taking care of by the language
14:16:55 [nick]
MarkB: Observer should be a URI i think
14:17:43 [nick]
MarkB: You should threat as an identifier
14:18:26 [nick]
Steven: It is a security issue
14:18:57 [nick]
MarkB: This can be handled by the engine
14:19:15 [nick]
John: In XForms we have a sandbox of DOMs
14:21:01 [Steven]
14:21:03 [nick]
John: We send xforms-insert and xforms-delete to the instance element not the node because it is in a different DOM tree
14:21:34 [nick]
John: You should be able to say which dom
14:21:48 [nick]
Charlie: you should be able to use XPath to address
14:22:42 [nick]
Paul: XPointer
14:23:20 [nick]
MarkB: I wonder if we can turn everything in XPointer and be backward compatible
14:23:46 [nick]
... for observer and ...
14:24:10 [nick]
Charlie: I have a couple of other editorial comments
14:24:23 [John_Boyer]
It has also been a problem that ev:target was an ID
14:24:39 [Steven]
How was that a problem John?
14:24:53 [John_Boyer]
This is the context for MarkB's comment about turning everything into an XPointer
14:25:00 [John_Boyer]
It is a problem because
14:25:02 [Steven]
Oh I see
14:25:11 [Steven]
Just being able to locate elements without an ID
14:25:38 [John_Boyer]
if I want to observe an event on repeat element but don't want to set it up as a child of repeat
14:25:50 [John_Boyer]
then I have to use ev:target with ID to indicate the repeat
14:26:28 [nick]
Paul: Aren't they classified by name
14:26:53 [nick]
MarkB: But then you need to know all events in front
14:27:56 [nick]
Charlie where done
14:29:32 [nick]
Leigh: Are you going to clarify how ID resolution is done in XML events 2
14:30:41 [nick]
MarkB: Itis section 6 after the editors note
14:31:19 [nick]
Paul: How is the context node found?
14:31:31 [nick]
MarkB: There isn't one
14:32:10 [nick]
* break
14:39:50 [unl]
unl has joined #forms
14:52:46 [nick]
TOPIC: Review of CURIE
14:53:37 [nick]
14:53:49 [nick]
John: Can we send this response
14:54:10 [nick]
Leigh: Should I sent it, or could you do it
14:54:44 [nick]
John: You can do it?
14:55:34 [John_Boyer]
14:56:53 [nick]
TOPIC: Determine relationship of encoding, charset and SOAP
14:57:06 [nick]
John: Paul can you help us?
14:57:33 [nick]
14:59:47 [nick]
15:05:32 [smaug]
smaug has joined #forms
15:08:01 [nick]
TOPIC: XForms Schema data-types
15:08:16 [nick]
Discussion about empty strings
15:08:37 [nick]
MarkB: It is a hack to allow the empty string in the schema data types
15:08:53 [nick]
MarkB: We should create emailOrEmpty
15:09:32 [nick]
John: We decided a long time ago that the xforms data-types should include the empty string
15:10:06 [nick]
MarkB: What is done is done, we can't do much about it
15:10:33 [nick]
Leigh: It is already decided
15:12:40 [nick]
Leigh: We can do that with minOccurrence
15:12:58 [nick]
MarkB: it doesn't apply on list, a list can be empty
15:13:14 [nick]
Leigh: OK, then we don't need to change it
15:13:39 [smaug]
Has anyone gone through the comments I sent over a year go about XML Events 2 ?
15:14:28 [Steven]
Hi Smaug, who are you?
15:15:04 [Steven]
Ah, Olli Pettay
15:15:45 [nick]
MarkB: It looks that a list can't be empty and that min and max occurrences applies on it
15:16:12 [nick]
Markb: minLength can be applied on list (this is what we need)
15:16:45 [smaug]
Steven: right
15:17:32 [smaug]
I think the problem mentioned in the latter email is fixed
15:17:43 [smaug]
but not the problems mentioned in the first one
15:19:26 [Steven]
It looks like you sent the comments to the wrong list Smaug
15:19:40 [smaug]
15:19:58 [Steven]
should have been www-html-editor
15:20:12 [smaug]
well, I sent those to markb too
15:20:20 [markbirbeck]
15:20:32 [markbirbeck]
"Any property identified as a having a set, subset or ·list· value may have an empty value unless this is explicitly ruled out: this is not the same as absent."
15:20:43 [Steven]
true, but www-html-editor mails get forwarded to the issue tracker
15:20:50 [markbirbeck]
So listItems can already be empty.
15:22:31 [nick]
So listitems allows the empty string
15:23:26 [nick]
John: listitem doesn't allows the empty string, but if the group thinks we can keep it like it is
15:24:57 [nick]
TOPIC: Submission @resource comment to RDFa
15:25:23 [nick]
15:26:12 [nick]
John: MarkB I want to make sure that we still believe that it just a comment to RDFa and we don't have not to change anything
15:29:22 [nick]
MarkB: As far as the RDFa group there is no problem
15:30:55 [nick]
MarkB: There is no behavior consequence in RDFa for the resource attribute
15:33:06 [nick]
John: Maybe there is nothing to say about it
15:33:15 [nick]
John: So it is done
15:35:29 [smaug]
Steven: should I resend the comments to www-html-editor?
15:40:19 [nick]
*meeting ends
15:41:19 [nick]
rrsagent, make minutes
15:41:19 [RRSAgent]
I have made the request to generate nick
15:41:26 [nick]
zakim, bye
15:41:37 [nick]
rrsagent, bye
15:41:37 [RRSAgent]
I see 1 open action item saved in :
15:41:37 [RRSAgent]
ACTION: MarkB to respond by Friday 13 June with our comments for Review of XML Http Request [1]
15:41:37 [RRSAgent]
recorded in