06:58:50 RRSAgent has joined #forms 06:58:50 logging to http://www.w3.org/2008/06/11-forms-irc 06:59:21 rrsagent, make log public 07:02:16 wellsk has joined #forms 07:09:50 klotz has joined #forms 07:10:00 ebruchez has joined #forms 07:19:20 Roger has joined #forms 07:19:30 Charlie has joined #forms 07:19:30 scribenick: klotz 07:20:13 unl has joined #forms 07:20:13 Rafael has joined #forms 07:20:35 topic: Streamlined Syntax 07:20:42 Steven has joined #forms 07:20:57 john: we've talked about an xforms aggregator module, really XForms Full Aggregator Module, and a Model Only. 07:21:14 rrsagent, make minutes 07:21:14 I have made the request to generate http://www.w3.org/2008/06/11-forms-minutes.html Steven 07:21:17 john: then a streamlined module, which adds all the additional attributes to ui controls. 07:21:42 john: does that seem like the right approach? add @relevant to input. 07:21:53 charlie: xf:input or html:input? that may imply a different driver, right? 07:22:13 charlie: it just occurs to me that i don't really recall where we had anticipated them going last month 07:22:20 john: i don't see why they can't go on our elements 07:22:27 charlie: as a streamlined syntax, it's one of our options 07:22:40 john: do we put all those attributes on our elements? 07:22:59 steven: we still have to discuss and resolve whether it's ok for us to import xforms wholesale into xhtml2 07:23:05 john: without namespaces 07:23:14 charlie: there are two uses, for ourselves, and as an onramp 07:23:41 leigh: i think xslt as a way to do it 07:24:22 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 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 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 john: so that module gives something for the transformation to aim at 07:26:41 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 nick: it's not a lot of adjustments i've made 07:29:20 nick: [projects changes] 07:31:24 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 leigh: is there a confusion between ref on submission and ref on submit 07:32:00 john: there is a difference 07:32:10 leigh: they're now defined in the same spot 07:32:20 steven: we use ref on submit 07:33:00 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 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 leigh: and bind 07:33:56 john: it will combine with ref on submit; submit has ref/bind/model; submission doesn't have the model attribute. 07:33:57 Yesterday's minutes now in place at http://www.w3.org/2008/06/10-forms-minutes.html 07:34:02 nick: model wasn't in this list. 07:34:12 nick: then you can't override what is submitted. 07:34:20 charlie: so you use these on the submit element? 07:34:37 charlie: then put submission as child of submit; it will look a little weird but it will be clear 07:35:06 nick: i wrote that local submission elements override the referred submission so you can specify the resource locally. 07:36:24 leigh: so if we had a child submission element it would take precedence in its attributes over the id-referenced submission 07:36:30 charlie: or only its attributes if there is no reference 07:37:31 erik: I see, so you can bind the trigger to another node to control relevance and we'd lose that. 07:37:47 john: why isn't it backwards compatible? 07:37:50 nick: ... 07:38:01 john: you can still do it by using a full submission element. 07:38:29 erik: it has a different behavior for existing code: submit/@ref now implies the data to submit 07:39:30 uli: wouldn't it be much easier to include a child element of submission on submit 07:40:16 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 erik: what was the initial goal for overriding attributes on the submit button? 07:40:48 nick: it was for streamlined syntax so you don't have to have a submission in the model 07:41:11 Meeting: Forms FtF, Amsterdam, Day 3 07:41:24 nick: it also allows you to change the src attribute in the submission for different submit controls 07:41:28 Chair: John 07:41:29 s/src/resource/ 07:41:46 erik: so this is for no model, no submission, all ui? 07:42:07 Present: Charlie, John, Erik, Leigh, Nick, Rogelio, Rafael, Steven 07:42:15 john: i think we can just say ref doesn't override. then it's time to write a submission element. 07:42:23 Regrets: MarkS 07:42:26 charlie: i'm a little worried about special-casing it. 07:42:28 rrsagent, make minutes 07:42:28 I have made the request to generate http://www.w3.org/2008/06/11-forms-minutes.html Steven 07:43:10 erik: the nested element solution isn't good for simple syntax 07:43:24 Agenda: http://lists.w3.org/Archives/Public/public-forms/2008Jun/0014.html 07:43:36 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 nick: are we making this change to submit or input? 07:43:54 Remote+Keith(remote) 07:44:12 john: it will happen from streamlined syntax 07:44:12 erik: but we don't have input type="submit" 07:44:31 rrsagent, make minutes 07:44:31 I have made the request to generate http://www.w3.org/2008/06/11-forms-minutes.html Steven 07:45:08 erik: xslt can produce a submission attribute 07:45:14 Present+Keith(remote) 07:45:23 nick: the sourceforge converter I posted does this, with modes in xslt 07:45:35 rrsagent, make minutes 07:45:35 I have made the request to generate http://www.w3.org/2008/06/11-forms-minutes.html Steven 07:46:29 john: so it should be possible to write the html or xhtml module for xforms to do this 07:46:52 erik: so input type="submit" is equivalent 07:48:57 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 s/hte/the/ 07:49:14 erik: so what is the next step for an existing html form? input type="submit". so what's t next step 07:49:56 john: that implies that we should have an input type="submit" that maps on to submission 07:50:49 leigh: we can define our own input type="submit" 07:55:34 leigh: but who would use it? i can understand an xslt that maps html4 input type="submit" 07:56:09 leigh: i can understand a module of xforms core additional support for the output of that transformation 07:56:39 leigh: but i can't understand a module that adds xf:input type="submit" to xforms; who would use it? 07:58:23 charlie: but we want a streamlined syntax for our xforms authors 07:58:48 steven: is it a moment of simplification and a lifetime of grief? 07:59:53 I don't see what it simplifies; MVC gives you long-term simflification 08:00:19 I see streamlines syntax as adding the font tag back into xhtml to help people us stylesheets! 08:00:24 s/lines/lined/ 08:00:33 s/us /use / 08:01:36 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 uli: is this xml? 08:02:30 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 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 charlie: but we want a simplified syntax 08:10:14 http://sourceforge.net/projects/xhtml-to-xforms 08:10:16 leigh: yes, that's great, but it's not necessarily the same syntax as the additions to html4. 08:11:31 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 leigh: Mark Birbeck and Paul Butcher arrive 08:16:26 present+MarkBirbeck 08:17:09 present+PaulButcher 08:17:18 rrsagent, make minutes 08:17:18 I have made the request to generate http://www.w3.org/2008/06/11-forms-minutes.html Steven 08:21:23 markbirbeck has joined #forms 08:23:43 Hey Keith. Are you managing to stay awake? 08:23:58 :) 08:37:03 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 Erik: The DOM is different for example 08:37:52 Nick: There are some HTML4 attributes that are hard to implement. 08:38:31 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 paul: What attributes are hard to implement? 08:38:50 Erik: I see more of a jump than a progressive ramping up 08:39:28 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 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 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 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 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 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 Leigh: I don't agree iwth the goal but 40% of example can convince me. 08:43:14 s/iwth/with 08:45:11 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 Leigh: That's the core Canonicalization problem. 08:49:26 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 Erik: ... 08:49:36 Nick: .. 08:49:38 Leigh: ... 08:50:11 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 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 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 Erik: But you're talking about how to implement ubiquity 08:52:39 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 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 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 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 Mark: ... 09:02:53 Leigh: ... 09:03:25 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 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 Paul: OK 09:04:25 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 Mark: What's the driving force for the abbreviated syntax? 09:04:47 Leigh: My question exactly 09:05:09 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 Mark: We already have a potential child element, send, and the attributes could go there. 09:06:09 Charlie: That also solves the event dispatch problem 09:06:23 John: How does it simplify anything? 09:07:01 Mark: I don't care too much about it anyway as I'm concerned on the HTML transformation 09:07:11 Erik: submit is simplified syntax for trigger+send 09:07:15 Mark: So why complicate it? 09:07:25 John: Because it doesn't have a submission element. 09:07:30 Mark: So what's wrong? 09:08:00 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 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 Erik: We tried that with the form element. So input type="submit" is all we need. 09:09:28 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 Uli: via javascript libraries 09:10:11 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 Nick: Nobody uses the action attribute on a form anyway; everybody uses javascript 09:10:52 Mark: You put it in the form action and the javascript does extra clever stuff. 09:11:29 Steven: But don't unknown attributes disappear from the dom in HTML5? 09:11:42 Steven: So doesn't that break adding attributes processed via Javascript? 09:11:48 * Break 09:16:57 Charlie: I quite like this idea of a deprecated chapter. 09:17:09 John: What's the difference between a chapter and another module? 09:17:52 Uli: I thought the idea of modules, for message, for example, does it start an xforms processor? 09:18:11 John: It causes a set of markup to begin working in an implementation specific way. 09:18:49 John: It's not done until we agree it's done...similar to the IDL discussion we had. 09:20:14 John: To control the one submission, it's ok but the submit element lets you say you have more than one. 09:20:21 Erik: Then you create a submission. 09:21:10 John: I'm not necessarily against it. The form element 09:24:41 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 Erik: I see the power of XForms as a way to make bigger forms, not for small form authors. 09:35:10 ... 09:35:33 Leigh: I don't see the attributes added to HTML4 necessary to add to core XForms. 09:35:57 Mark: How about an XHTML1.1 module of attributes from XForms? 09:36:16 Charlie: That's what we're proposing but a twist, an XHTML1.1 module, not an XForms module. 09:36:26 leigh: it's a key difference, not a twist. 09:37:53 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 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 Erik: Should we be using the webforms attribute names? 09:43:48 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 Charlie: So can we agree to produce the XHTML modules? 09:44:13 Nick: We agreed in Raleigh. 09:44:18 Charlie: That was modules for XForms. 09:44:31 Nick: There is still work, which Mark did, but no concrete module. 09:44:38 John: There is the syntax example for PO. 09:44:51 John: Now we have more clarity and can turn that into a module. 09:45:16 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 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 John: So you could have submission without data. 09:46:13 Charlie: We have that yesterday. 09:47:01 Mark: So that would be perfect for XHTML. 09:47:01 Mark: We could have an XHTML modularization module with several attributes, no ref. 09:47:02 Charlie: We did that yesterday for XForms; we can use it on XHTML. Then we go on and do another one. 09:47:08 Mark: Not in the same module. 09:47:18 Charlie: Yes. 09:47:33 John: Does wrap up mean a rec-track document? 09:47:38 Leigh: Yes, that's what Mark is saying. 09:48:43 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 s/tey/they/ 09:49:25 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 s/ hte / the /G 09:50:05 Mark: If you follow xhtml modularization each spec has to say something about the glue. 09:50:59 much better 09:51:01 Mark: So maybe we should just pick the uncontroversial attributes, the ones you did yesterday. 09:51:17 Charlie: We scrubbed the modelness out of it. 09:51:51 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 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 Mark: We can use the role attribute as a model. 09:52:51 John: Is it in SpecXML? 09:52:53 Steven: no. 09:53:07 It is in ShaneML 09:53:26 Erik: We have three attributes from wherever; what about xforms submission? Does that stay ? Does it get imported into HTML? 09:53:36 Mark: I believe so. Then it can be imported into SVG, as in the backplane. 09:54:08 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 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 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 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 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 Charlie: We wanted to avoid the submission module knowing about refs. 09:57:24 Charlie: There's a tipping point; at some point you need a place to put that logic. 09:57:57 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 John: Those are prose descriptions. 09:58:20 Erik: Then if we include this module, input name creates this data model in the background. 09:58:27 Mark: Submission doesn't care about its data model. 09:58:33 Erik: It assumes it's a data model. 09:58:42 Mark: It's capable of transmitting XML but it can do other things. 09:58:46 Erik: It's not JSON, it's XML. 09:59:04 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 Paul: In that sort of module, where do you see relevance and validity? That's about submission? 10:00:08 John: This afternoon we should have the work jam where we look at the module breakdown. 10:01:22 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 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 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 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 Erik: And it's not clear that an XPath API is suitable for a JSON data model anyway. 10:03:55 * Lunch 10:04:10 s/* Lunch// 10:06:55 Paul: Can we consider submission and serialization as two separate modules? 10:07:28 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 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 Erik: Just the time and energy. 10:08:56 Charlie: We factored out data model yesterday. Another pass could factor out serialization. 10:09:12 Erik: I just think it's a lot of effort. 10:09:18 Mark: It would be for adoption. 10:10:38 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 Erik: People take what is working and use it, like Dojo. 10:11:47 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 Erik: XForms has complexity as well: we need dialogs, model packaging, etc. Providing submission to others doesn't solve my problems. 10:12:49 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 Erik: XForms does well for forms. I'm not sure Silverlight and Flex are good for forms. 10:13:54 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 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 Charlie: I'm surprised to hear that rich web app pure plays are not competitors. 10:15:29 Mark: It's the architecture. When we've got these architectures going, we can be the onramp for silverlight. 10:16:00 Mark: Flex is different because it is the entire thing. 10:17:00 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 Mark: I agree; src for model is something I've talked about. 10:17:45 John: Why did you boot it out of 1.2, nested modules? 10:17:50 Erik: The whole 1.2 thing isn't it for me. 10:22:51 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 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 Erik: Who here wants to work on HTML compatibility? 10:23:33 John: I agree with Mark that we want more customers. 10:23:48 Erik: Maybe you're achieving this with ubiquity. 10:24:22 John: It's one solution proposed. There were two main complaints about xforms: browser availability and authoring ability. 10:24:27 Erik: Simplification is great. 10:24:50 John: It's a pre-sales problem. 10:28:57 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 Erik: XProc is moving forward in this way. 10:30:36 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 John: You spend a year and a half trying to modularize everything. 10:31:06 Erik: I don't have that problem. I have the problem of 10,000 line forms. 10:31:19 John: So you don't have modularization within the form. 10:36:21 prb has joined #forms 10:43:02 prb is Paul Butcher, webBackplane 12:22:56 wellsk has joined #forms 12:31:59 Charlie has joined #forms 12:32:22 klotz has joined #forms 12:34:13 unl has joined #forms 12:38:18 prb has joined #forms 12:38:26 John_Boyer has joined #forms 12:49:02 https://na1.connect.acrobat.com/orbeon 13:14:52 Steven has joined #forms 13:31:28 scribe: nick 13:32:56 http://lists.w3.org/Archives/Public/www-forms/2008Jun/0001.html 13:33:36 Topic:Review of XML Http Request 13:33:49 s/Topic/TOPIC/ 13:34:53 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 MarkB: Our comments can't be 'they should add event X' 13:36:04 MarkB: We should comment on problems that prevent us re-using the spec 13:36:46 MarkB: They depend on HTML5 and the Window object which is a problem for us to reuse it 13:37:59 MarkB: We should sent a positive response asking to remove the unnecessary dependencies 13:38:32 MarkB: We should use it in future versions 13:39:15 MarkB: They are already thinking about future versions of the spec 13:39:38 MarkB: We should give input on it 13:40:05 Charlie: We shouldn't have a one on one mapping if they add events, we could wrap their evenets 13:40:15 s/evenets/events/ 13:41:31 Charlie: Do you think their dependency on window or HTML5 is political 13:41:42 MarkB: I think so 13:42:27 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 Leigh: They can give an abstract spec and add a javascript binding 13:43:48 MarkB: They depend on HTML5 because window is defined in it 13:44:41 John: LC period is over, but the HTC gave us an extension, so we have to report soon 13:44:48 MarkB: I can do it today 13:46:08 ACTION: MarkB to respond by Friday 13 June with our comments for Review of XML Http Request 13:46:08 Sorry, couldn't find user - MarkB 13:47:36 John: You want to send some comments on the base URI? 13:49:33 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 John: Isn't it a security problem? 13:50:45 MarkB: It could be read-only in a browser environment? 13:51:22 John: Do you not always have a containing document, which provides the base URI 13:51:29 Uli: Server side javascript 13:51:33 John: OK 13:51:47 MarkB: In sidewinder .... 13:52:36 MarkB: Explains how a relative URI is resolved in an XML application 13:52:51 rrsagent, here? 13:52:51 See http://www.w3.org/2008/06/11-forms-irc#T13-52-51 13:53:46 TOPIC: Review of XML Events 2 13:53:53 http://www.w3.org/TR/xml-events2/ 13:54:15 http://lists.w3.org/Archives/Public/public-forms/2008Jun/0017.html 13:54:47 Charlie: Most is editorial, the spec is overall good 13:55:43 http://www.w3.org/MarkUp/2008/ED-xml-events-20080604/ 13:56:48 Charlie: introduction section 13:57:35 Charlie:The text isn't up to date with Event flow in DOM3 13:58:47 John: The actual diagram still lets me believe that capture goes to the target, which isn't the case 13:59:11 MarkB: XML events 2 is based on DOM 2 events 14:00:25 ... (differences between DOM 3 events and DOM 2 events, groups, hierarchy) 14:00:45 John: The abstract states DOM level 3 events 14:01:09 MarkB: When we wrote this DOM level 3 didn't had three phases 14:01:54 John: DOM level 3 clearly states that capture doesn't goes to the target 14:02:42 MarkB: There is a flag atTarget in DOM level 2 events 14:03:17 MarkB: DOM level 3 has a notion of a third phase, this is a problem 14:04:27 John: The target phase of DOM level 3 is bubble and atTarget in DOM level 2 14:05:23 Charlie: Should we request an other version that is based on DOM level 2 14:05:49 Steven: XML events is just a syntax 14:07:01 MarkB: We should send a comment that DOM level 3 is required, DOM level 2 should be enough 14:07:58 John: I would have hoped that events could flow between different documents without changing the phase 14:08:38 John: At the cut point the event goes in target phase, this is a problem 14:09:04 MarkB: This is well documented in XBL 14:10:27 MarkB: He has the notion of forwarding, but you don't need it you can also hide it 14:10:50 MarkB: We do this a lot with HTML events 14:11:38 John: Is it available somewhere else then in XBL 14:11:51 MarkB: NO, maybe it should be in XML events 2 14:11:57 John: I think so 14:12:14 MarkB: Add it to the comment we send 14:13:01 Charlie: Are you allowed to listen for events in another DOM? 14:13:14 s/DOM/DOM tree/ 14:14:15 ... talking about remote handlers and remote observers 14:15:38 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 Leigh: The resolving can be taking care of by the language 14:16:55 MarkB: Observer should be a URI i think 14:17:43 MarkB: You should threat as an identifier 14:18:26 Steven: It is a security issue 14:18:57 MarkB: This can be handled by the engine 14:19:15 John: In XForms we have a sandbox of DOMs 14:21:01 s/threat/treat/ 14:21:03 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 John: You should be able to say which dom 14:21:48 Charlie: you should be able to use XPath to address 14:22:42 Paul: XPointer 14:23:20 MarkB: I wonder if we can turn everything in XPointer and be backward compatible 14:23:46 ... for observer and ... 14:24:10 Charlie: I have a couple of other editorial comments 14:24:23 It has also been a problem that ev:target was an ID 14:24:39 How was that a problem John? 14:24:53 This is the context for MarkB's comment about turning everything into an XPointer 14:25:00 It is a problem because 14:25:02 Oh I see 14:25:11 Just being able to locate elements without an ID 14:25:38 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 then I have to use ev:target with ID to indicate the repeat 14:26:28 Paul: Aren't they classified by name 14:26:53 MarkB: But then you need to know all events in front 14:27:56 Charlie where done 14:29:32 Leigh: Are you going to clarify how ID resolution is done in XML events 2 14:30:41 MarkB: Itis section 6 after the editors note 14:31:19 Paul: How is the context node found? 14:31:31 MarkB: There isn't one 14:32:10 * break 14:39:50 unl has joined #forms 14:52:46 TOPIC: Review of CURIE 14:53:37 http://lists.w3.org/Archives/Public/public-forms/2008Jun/0019.html 14:53:49 John: Can we send this response 14:54:10 Leigh: Should I sent it, or could you do it 14:54:44 John: You can do it? 14:55:34 http://lists.w3.org/Archives/Public/public-forms/2008Jun/0014.html 14:56:53 TOPIC: Determine relationship of encoding, charset and SOAP 14:57:06 John: Paul can you help us? 14:57:33 http://lists.w3.org/Archives/Public/www-forms/2007Mar/0060.html 14:59:47 http://www.w3.org/MarkUp/Forms/2007/XForms-11-Schema.xsd 15:05:32 smaug has joined #forms 15:08:01 TOPIC: XForms Schema data-types 15:08:16 Discussion about empty strings 15:08:37 MarkB: It is a hack to allow the empty string in the schema data types 15:08:53 MarkB: We should create emailOrEmpty 15:09:32 John: We decided a long time ago that the xforms data-types should include the empty string 15:10:06 MarkB: What is done is done, we can't do much about it 15:10:33 Leigh: It is already decided 15:12:40 Leigh: We can do that with minOccurrence 15:12:58 MarkB: it doesn't apply on list, a list can be empty 15:13:14 Leigh: OK, then we don't need to change it 15:13:39 Has anyone gone through the comments I sent over a year go about XML Events 2 http://lists.w3.org/Archives/Public/www-forms/2007Feb/0093.html http://lists.w3.org/Archives/Public/www-forms/2008Jan/0000.html ? 15:14:28 Hi Smaug, who are you? 15:15:04 Ah, Olli Pettay 15:15:45 MarkB: It looks that a list can't be empty and that min and max occurrences applies on it 15:16:12 Markb: minLength can be applied on list (this is what we need) 15:16:45 Steven: right 15:17:32 I think the problem mentioned in the latter email is fixed 15:17:43 but not the problems mentioned in the first one 15:19:26 It looks like you sent the comments to the wrong list Smaug 15:19:40 oh 15:19:58 should have been www-html-editor 15:20:12 well, I sent those to markb too 15:20:20 http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#datatype-components 15:20:32 "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 true, but www-html-editor mails get forwarded to the issue tracker 15:20:50 So listItems can already be empty. 15:22:31 So listitems allows the empty string 15:23:26 John: listitem doesn't allows the empty string, but if the group thinks we can keep it like it is 15:24:57 TOPIC: Submission @resource comment to RDFa 15:25:23 http://lists.w3.org/Archives/Public/public-forms/2008Apr/att-0132/2008-04-30.html#ACTION1 15:26:12 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 MarkB: As far as the RDFa group there is no problem 15:30:55 MarkB: There is no behavior consequence in RDFa for the resource attribute 15:33:06 John: Maybe there is nothing to say about it 15:33:15 John: So it is done 15:35:29 Steven: should I resend the comments to www-html-editor? 15:40:19 *meeting ends 15:41:19 rrsagent, make minutes 15:41:19 I have made the request to generate http://www.w3.org/2008/06/11-forms-minutes.html nick 15:41:26 zakim, bye 15:41:37 rrsagent, bye 15:41:37 I see 1 open action item saved in http://www.w3.org/2008/06/11-forms-actions.rdf : 15:41:37 ACTION: MarkB to respond by Friday 13 June with our comments for Review of XML Http Request [1] 15:41:37 recorded in http://www.w3.org/2008/06/11-forms-irc#T13-46-08