07:11:43 RRSAgent has joined #forms 07:11:43 logging to http://www.w3.org/2008/06/10-forms-irc 07:11:49 rrsagent, make log public 07:17:17 Rafael has joined #forms 07:18:26 unl has joined #forms 07:18:33 Steven has joined #forms 07:18:55 scribe: John 07:19:04 scribenick: John_Boyer 07:19:10 Topic: Review of CURIE spec 07:19:36 http://www.w3.org/TR/2008/WD-curie-20080506/ 07:19:57 Roger has joined #forms 07:20:09 Leigh: has three questions 07:20:24 default prefix vs. host language defaults 07:20:25 Leigh: default prefix versus host language defaults 07:20:27 safe_curies and curies 07:20:35 Schema 07:20:45 Leigh: default prefix... 07:20:51 ebruchez has joined #forms 07:20:59 Leigh: A host language may define a set of namespaces 07:21:13 Steven has changed the topic to: XForms FtF, Amsterdam 07:21:14 Leigh: CURIE is defined to work with XML and non-XML 07:21:26 Leigh: What is the mechanism for declaring default prefix? 07:21:54 Leigh: Remembers discussion of default NS applying to attributes. 07:22:21 Leigh: what is defaulting mech. for XML apps? 07:22:29 Steven: Use case was RDFa 07:22:42 Relations between URIs expressed by a URI 07:23:07 You don't want to be staring at those URIs all the time, so you want CURIEs to look like QNames 07:24:00 Make a new datatype, compact URI, specifies a mapping from prefix:postfix to a URI 07:24:35 Steven: take uri represented by prefix and append the postfix 07:26:03 Leigh: Do authors define the mapping or does XML have a standard way? 07:26:11 Steven: XML has a standard way 07:26:18 Steven: dc:creator is CURIE for {whatever NS dc is mapped to}postfix 07:26:33 Charlie: So you have to set up the prefix to have a trailing slash 07:26:54 my:/foo/bar#bla 07:27:04 Steven: But you could put the slash in the postfix because CURIE is a superset of QName 07:27:15 iptc:1234 07:27:47 Steven: One other bit. This is to go in XHTML 07:28:04 Steven: Have rel= in XHTML now, but want to say rel="dc:creator" 07:28:19 Steven: But still want indexing to work. Problem is that default namespaces don't quite cut it 07:28:38 Steven: So host language has to declare how non-prefixed CURIEs work 07:29:00 Leigh: The default prefix for unprefixed CURIEs is set by the host language, and that is defined by prose 07:29:25 Leigh: What about XML apps that are not namespace aware? 07:29:42 Steven: If they are not namespace aware, then they have to specify how the prefixes will work 07:30:36 Leigh: You should give guidance to app authors on what they *should* do. E.g. CDF is allergic to namespaces, but they would accept people typing dc:creator 07:31:17 Leigh: Give some guidance to "should allow namespace prefixes to declare prefixes for CURIEs but may use another mechanism" 07:31:37 Steven_ has joined #forms 07:31:47 Leigh: Second issue: difference between reserved values and default prefix 07:32:10 Leigh: consider XForms could use a CURIE for appearance attribute 07:32:31 Leigh: could define that as having default prefix for full,compact,minimal 07:33:10 Leigh: Can reserved values be used without a prefix? 07:33:13 Steven: yes 07:36:25 Charlie has joined #forms 07:36:40 unl has joined #forms 07:36:57 John_Boyer has joined #forms 07:37:10 ebruchez has joined #forms 07:37:24 Leigh: Second and one half issue: Safe CURIEs 07:37:57 Rafael has joined #forms 07:37:57 Roger has joined #forms 07:38:05 nick has joined #forms 07:38:31 klotz has joined #forms 07:39:18 Steven has joined #forms 07:40:17 Leigh: Is it OK for XForms to say CURIE and not safe CURIE? 07:40:37 Steven: A safe CURIE is a just a CURIE with curly braces around it to ensure you can't have a regular URI 07:40:55 Leigh: OK, so schema only defines a datatype. no binding to a particular attribute or element. 07:41:00 Leigh: In fact no binding to XML. 07:41:06 Leigh: No comments about the schema 07:41:21 Steven: Can you send in the comments where you said "it would be good if you did this"? 07:41:35 Leigh: Yes. Give more guidance to XML apps 07:41:58 Leigh is writing email feedback 07:42:17 rrsagent, make log public 07:42:17 Leigh: Let people know that they can define a different default NS than the default NS for their application 07:42:40 rrsagent, make minutes 07:42:40 I have made the request to generate http://www.w3.org/2008/06/10-forms-minutes.html Steven 07:42:43 Leigh: Need an example of reserved values 07:43:07 Leigh: I thought default NS and reserved values were two routes to the same end, but in fact they are used in concert to achieve one thing 07:43:38 Leigh: State clearly that you're not required to support safe CURIE 07:43:56 scribe: Leigh 07:44:04 scribenick: klotz 07:45:43 Steven_ has joined #forms 07:45:56 Present: Nick, Uli, Charlie, John, Erik, Leigh, Rafael, Rogelio, Steven, Keith(remote) 07:46:01 Regrets: MarkS 07:46:07 rrsagent, make minutes 07:46:07 I have made the request to generate http://www.w3.org/2008/06/10-forms-minutes.html Steven_ 07:46:31 Chair: John 07:46:36 rrsagent, make minutes 07:46:36 I have made the request to generate http://www.w3.org/2008/06/10-forms-minutes.html Steven_ 07:47:03 Meeting: XForms FtF, Amsterdam, Day 2 07:47:09 rrsagent, make minutes 07:47:09 I have made the request to generate http://www.w3.org/2008/06/10-forms-minutes.html Steven_ 07:47:29 Agenda: http://lists.w3.org/Archives/Public/public-forms/2008Jun/0014.html 07:47:36 http://www.w3.org/TR/2007/WD-access-control-20071001/ 07:49:48 Topic: Data module 08:16:28 See http://www.alphaworks.ibm.com/tech/collage for an example of extending constraints to the UI 08:47:12 unl has joined #forms 08:56:49 http://xformstest.org/2008-06-10.txt 09:02:32 ACTION: Charlie Wiecha to provide spec XML for instance chapter. 09:02:32 Sorry, couldn't find user - Charlie 09:41:46 http://xformstest.org/2008-06-10.txt 10:00:49 Lunch 11:39:46 unl has joined #forms 11:40:34 Charlie has joined #forms 11:44:57 klotz has joined #forms 11:44:59 klotz_ has joined #forms 11:45:14 klotz_ has left #forms 11:49:15 topic: CURIE review 11:49:15 Leigh: ... 11:49:15 Steven: ... 11:49:15 Leigh: I will send email. 11:49:15 topic: Access Control Review 11:49:16 John: Leigh, what is the status of this? 11:49:18 Leigh: We're done with our comments. No further action is necessary. I saw Mozilla may be implemnenting something related to this. 11:49:21 Nick: I'll mark it closed. 11:49:23 topic: Data Module 11:49:25 Charlie: I realized we did a data module on AlphaWorks. I have methods we have overlooked. We don't have any way to control the src attribute, or construct the instance, or replace. We don't have serialize, load, or anything else. 11:49:32 Leigh: Didn't Mark say that belongs in submission? 11:49:33 Charlie: Isn't that a 1.2 thing? 11:49:35 Leigh: Why not just define it in submission. 11:49:37 John: Becuase of the events. There's a nontrivial play between src and resource. If it has inline data and a resource attribute, ... 11:49:40 Leigh: I think we should no question have a way to set the document from a node. I think setting it from a URI belongs in the submission module because it knows about XML serialiation and deserialization. 11:49:43 Charlie: Or in another "serialization" module. 11:49:45 Leigh: That sounds fine, just not in the instance module. Not with a URI. 11:49:47 Charlie: That smacks of network access, yes. 11:49:49 John: OK. So we need setdocument or just replace? 11:49:51 Charlie: Is the root element all? 11:49:53 John: There's other stuff. 11:49:55 Nick: How about reset? 11:49:57 John: That would be the model module. 11:50:01 Charlie: Do we want constructors? To create instances? Language binding? 11:50:03 Leigh: I can the value of a JavaScript binding listed explicitly, as is done with DOM and the Java binding, but not yet. I don't know how to write IDL for constructors. 11:50:06 Charlie: The notation. 11:50:08 Leigh: Do you have any mind some parameters for constructors? 11:50:10 Charlie: No, just loading contents. 11:50:12 Leigh: So if there aren't any parameters then we don't need a constructor. 11:50:14 Charlie: validation ought to be in logic. 11:50:17 John: Yes. There will be a data properties module for the properties, but now how to set them. Maybe the model module will have a validation module with type, constraint, required, and schema. 11:50:19 scribenick: klotz 11:50:21 rrsagent, scribenick klotz 11:50:21 I'm logging. I don't understand 'scribenick klotz', klotz. Try /msg RRSAgent help 11:51:16 topic: CURIE review 11:51:16 Leigh: ... 11:51:16 Steven: ... 11:51:16 Leigh: I will send email. 11:51:16 topic: Access Control Review 11:51:17 John: Leigh, what is the status of this? 11:51:19 Leigh: We're done with our comments. No further action is necessary. I saw Mozilla may be implemnenting something related to this. 11:51:22 Nick: I'll mark it closed. 11:51:24 topic: Data Module 11:51:26 Charlie: I realized we did a data module on AlphaWorks. I have methods we have overlooked. We don't have any way to control the src attribute, or construct the instance, or replace. We don't have serialize, load, or anything else. 11:51:32 Leigh: Didn't Mark say that belongs in submission? 11:51:34 Charlie: Isn't that a 1.2 thing? 11:51:36 Leigh: Why not just define it in submission. 11:51:38 John: Becuase of the events. There's a nontrivial play between src and resource. If it has inline data and a resource attribute, ... 11:51:41 Leigh: I think we should no question have a way to set the document from a node. I think setting it from a URI belongs in the submission module because it knows about XML serialiation and deserialization. 11:51:44 Charlie: Or in another "serialization" module. 11:51:46 Leigh: That sounds fine, just not in the instance module. Not with a URI. 11:51:48 Charlie: That smacks of network access, yes. 11:51:50 John: OK. So we need setdocument or just replace? 11:51:52 Charlie: Is the root element all? 11:51:54 John: There's other stuff. 11:51:56 Nick: How about reset? 11:52:05 John: That would be the model module. 11:52:05 Charlie: Do we want constructors? To create instances? Language binding? 11:52:05 Leigh: I can the value of a JavaScript binding listed explicitly, as is done with DOM and the Java binding, but not yet. I don't know how to write IDL for constructors. 11:52:48 Charlie: The notation. 11:52:48 Leigh: Do you have any mind some parameters for constructors? 11:52:48 Charlie: No, just loading contents. 11:52:48 Leigh: So if there aren't any parameters then we don't need a constructor. 11:52:48 Charlie: validation ought to be in logic. 11:52:49 John: Yes. There will be a data properties module for the properties, but now how to set them. Maybe the model module will have a validation module with type, constraint, required, and schema. 11:52:52 Leigh: You could argue that type includes schema datatypes, and schema is full structure, but let's discuss it later. 11:52:55 Charlie: I don't see a way to re-use this for JSON without putting a DOM interface on it. One hope was that if we returned Object instead of Document we'd be able to defer navigational work to the user, and it could be cast as JavaScript vs DOM. There's only one way in the logic model to get the dependency graph. 11:52:59 Leigh: Why not have the JSON module add a get-as-json to the instance module. 11:53:03 Charlie: Because it would ripple through the dependency module. 11:53:06 Steven: Isn't it modular enough to access the data via JSON? To me, modularization is syntactic and you're adding this to the programming interface as well. 11:53:08 Erik: I think it would be a huge amount of work. Agreeing on the APIs would be hard. 11:53:10 Steven: In a sense, this group is not about defining APIs. 11:53:12 Uli: This seems to be an API for an XForms processor. 11:53:15 Steven: I'd be happy if we define the interface between the document author and the end user and not worry about what's in between. How to get down on paper what to achieve and how the end-user gets it. What happens in the middle should be as loose as possible. 11:53:18 Leigh: I proposed using IDL instead of Events because the events weren't doing it for us. 11:53:20 Steven: I don't agree with that axiom. 11:53:22 Erik: We should assume that modules would communicate however they need, events, or interfaces. 11:53:24 Charlie: Steven says that modularization is perhaps about syntax. 11:53:26 Steven: I see events as an admission of failure, that markup can't do everything, that we don't know the use cases. Ideally, you'd like to say that declaratively. 11:53:29 Erik: In XML Events a processor could so it statically. 11:53:33 Steven: Saying what rather than insert. I very much want structural constraints; you just get them automatically. 11:53:36 Erik: I wouldn't say it's a failure. 11:53:38 Steven: Then an admission that we don't know all use cases. 11:53:40 Erik: Maybe a concrete proposal could change the approach. Were there proposals? 11:53:42 Charlie: Our constraint engine doesn't 11:53:44 extend out to the UI so we have events there, but it's implicit on the model. Maybe we'll see fewer implicit event handlers on the actions. 11:53:47 Erik: They're not exactly imperative, as Mark Birbeck says. 11:53:49 John: They're declaratively tailored. 11:53:51 Erik: They're easiser to analyze than JavaScript. 11:53:53 Steven: An example: a typical thing is the "Save" button only activated when there's something to save. We can't declaratively say that. But you can catch value-changed and insert and delete events and make the save button relevant, and then submit-done makes it irrelevant. The events mechanism lets you deal with this use case that we don't yet do declaratively. 11:53:58 Erik: Yes. There's a larger set o fuse cases that are similar. 11:54:02 Charlie: I poosted a link to our Collage language, which extends constraints to the UI. http://www.alphaworks.ibm.com/tech/collage 11:54:05 Erik: Back to events and modules, perhaps we should say that we don't say how they communicate. 11:54:07 Leigh: I'm happy to say that IDL isn't going to work for us to describe the relationship between modules, but I don't want to go back to using events as the mechanism because I don't think it works. 11:54:10 Uli: It works in Chiba. 11:54:12 Nick: The core in Chiba uses events to communicate with the UI. 11:54:15 Leigh: Yes, but Chiba uses the chiba-stage-changed message as a catch-all to fix the problems where the events are not sufficient for implementation. 11:54:17 Erik: ... 11:54:19 John: ... 11:54:21 Steven: ... 11:54:23 John: I think we are likely to mess it up whether we use events or IDL. 11:54:25 Erik: I think we had a consensus that standardization of events. 11:54:27 John: What does it mean for modularization? 11:54:29 Erik: What problem does it solve to express all this? We have other things to do. It's not useful to anybody. 11:54:33 Nick: It's going to use our resources to add zero functionality for the user. 11:54:36 Leigh: I think the use case is using XForms in a JavaScript application. 11:54:37 Charlie: Maybe we don't need the programming model for that. 11:54:39 Erik: If we have that use case, then what do we need to provide to get the module to work to be interoperable? 11:54:41 John: All they need is markup. 11:54:43 Erik: If that's enough then we stop there. 11:54:45 Leigh: We start there. 11:54:47 John: If we don't have IDL then all they can do is call insert. 11:54:49 Leigh: So let's just do the syntax, finish that, and separately hear about JavaScript implementations of one or more modules and see where that goes. 11:54:52 Erik: So let's just refactor 1.1 into 1.2 and not add new features. 11:54:54 John: Except for the onramp syntax features. So do we delete this IDL from the wiki? 11:54:56 Charlie: No, let's leave it as an artifact. 11:54:58 topic: Break 11:57:18 topic: Instance module 11:57:18 John: Do we need a separate module for src and resource? 11:57:18 Charlie: No, let's put them in. 11:57:18 Steven: I personally don't have the need for it. I heard someone say yesterday that you never need to import anything outside. On the other hand, there's another point of view that says applications that don't need to initialize it just don't use that attribute. 11:57:21 John: So the module defines a minimal conformant module has to implement the attributes. 11:57:23 Charlie: Can we make it optional? 11:57:25 John: Yes, RFC 2118. 11:57:27 Charlie: It's onerous to say they must implement it. I just want fewer modules. 11:57:29 John: Currently they're a must. 11:57:31 Leigh: In our XForms driver module can we have a conformance profile that ... 11:57:33 Charlie: Promotes them, yes. 11:57:35 John: Who will do the schema magic now that we have the table? 11:57:37 Steven: Mark. 11:57:41 Charlie: Maybe we can have Mark do this tomorrow. 11:57:43 John: So we need a chapter in XForms 1.2 that says "instance module" and it will have the instance element and these three actions: setvalue, insert, and delete. 11:57:47 Leigh: And IDL for getInstanceDocument 11:57:48 Nick: That's on model because it takes an ID. 11:57:50 John: So we move this into one chapter. 11:57:52 Nick: So there's a lot of moving. 11:57:54 John: There's a lot of test-suite re-org. 11:57:56 John: Who will re-organize the spec? 11:57:58 Charlie: Per module? 11:58:01 John: OK. 11:58:02 Charlie: I can do it for the instance module. 11:58:04 Nick: I made some changes to submit. 11:58:06 John: We should talk about those. 11:58:10 Charlie: I'm happy to work on the instance module. 11:58:12 ACTION: Charlie Wiecha to provide spec XML for instance chapter. 11:58:12 Sorry, couldn't find user - Charlie 11:58:14 topic: Properties Module 11:58:16 John: This doesn't fit in anyway now as it's just IDL and it's a cut-and-paste error as user-defined MIPs are 2.0. We shouldn't do anything that's not powerful enough and limit ourselves. 11:58:19 Charlie: That was quick. 11:58:21 John: So formally we have no data properties module. The idea of abstracting out the data properties has no markup representation. 11:58:24 Charlie: It has bind and nodeset, and we could leave the other attributes to logic. 11:58:26 Leigh: You could define element versions of the bind attributes using reserved words for names, and then have XForms 2.0 allow the use of CURIEs for the names. 11:58:29 John: We need a way to describe the default behavior of readonly. 11:58:32 Erik: You can split up the module later and leave it in bind. 11:58:33 John: So we remove the properties module from 1.2. 11:58:35 topic: Model Module 11:58:38 John: Do we want to break model down into more modules? It might be that a validation module would be good. Or a schema and a validation module. 11:58:42 Charlie: Is that different from logic? 11:58:44 John: Part of logic. It would have constraint, type, and required. 11:58:46 Nick: There's a bind module already. 11:58:48 John: ... 11:58:52 Charlie: I like separating validation from the constraint graph. 11:58:54 John: The submission module needs to have validation and relevance. If you don't have relevance, then submission will behave differently. We now have some dependence on a readonly module. 11:58:57 Charlie: I would hope it's possible to do submission without validation. 11:58:59 John: The xforms-submit event gets dispatched; we now claim that we do the relevance pruning and validation as part of the default handling. So we could have the validation module take the xforms-submit event and set a property. The relevance module would also. 11:59:03 Nick: You probably don't want to set the property there. 11:59:05 Charlie: The driver that combines the two would define the property. 11:59:09 Nick: Why not just cancel the event? 11:59:11 Charlie: You might want to know why. 11:59:13 Leigh: It seems like the driver should do the cancel and signal other. 11:59:15 John: You could put the reason in the context. 11:59:17 Charlie: ... 11:59:19 John: The submission module would define reasons for termination in the context info. 11:59:21 Erik: The submission must do stuff first; ref attribute, extract attribute. Then the validation happens. You can't do that as part of submit. 11:59:24 John: We may need more events. 11:59:26 Leigh: We said we'd do this in prose. 11:59:28 Erik: I thought that we weren't going to go this route. 11:59:31 John: How do the modules communicate at runtime? 11:59:32 Erik: That's implementation-defined. When we define submission, we avoid dependencies between modules, but say that submission is aware of relevance property set by another module. If someone doesn't have relevance, then ignore it. 11:59:36 John: It doesn't make sense that we're not going to do this through events. If we do it with an ad-hoc mechanism then we have no way to put in modules that have no way to talk to us. 11:59:41 Charlie: It reduces interoperability. 11:59:43 John: They'd have a defined way to put in a implementation of a validation. 11:59:45 Nick: If you want pluggable modules, then you have to define events and IDL. 11:59:47 John: All I need is a boolean in the xforms-submit. 11:59:49 Erik: A new event actually. 11:59:51 John: I think the events aren't working for us because of the complicated processing model. We need more. 11:59:53 Erik: I have a bias against adding events. For the UI vs. the model, we may need more. So why not specify all communcation between modules with events? It might never end. I don't see the priority. 11:59:56 Leigh: Isn't this the discussion we had this morning and we decided to do it in prose? 11:59:58 John: We either have one mono-lithic thing or bits and pieces. 12:00:00 Charlie: The goal was to have it integrated in, say Dojo. 12:00:02 John: And we can't do that in prose. 12:00:04 Erik: We don't need to be that generic yet. As Leigh posted yesterday (I don't remember the acronym). 12:00:06 Leigh: YAGNI 12:00:10 Erik: You can still use the submission module. Someone may want to add a property but it's hypothetical. 12:00:12 John: We'd like to tease apart the modules at least to the point that submission could work without relevance and validity. That would be enough. 12:00:15 Erik: Submission needs access to data. It needs a notion of relevance and validity. It triggers revalidation and and recalculation. 12:00:18 John: Without dispatching events. 12:00:20 Erik: ... it could dispatch generic events 12:00:22 John: How do modules find that each other exists? 12:00:24 Raphael: A discovery mechanism 12:00:26 Steven: It's not dynamic. You define a language. 12:00:28 John: So you define it in prose, "if combined with the relevance module." 12:00:30 Leigh: It would be the XForms driver that combines submission and relevant. 12:00:32 Charlie: ...yes 12:00:34 John: That's ugly. Where do we put default processing? 12:00:36 Charlie: The driver has to inject in the default processing. Only the driver knows it, since we aren't using ecvents. 12:00:41 Erik: In the implementation we need hooks. 12:00:43 Nick: Doesn't the spec need to define the hooks? 12:00:45 Erik: We might not anticipate them all. 12:00:47 John: Existence, relevance, validation, and readonly. 12:00:49 Nick: Some other language defines how they work together. 12:00:51 John: Readonly only comes into play if you mix the readonly with the model. It doesn't come from the data model. 12:00:54 Leigh: So you name those four sections in submission and then in the XForms driver you say what the steps are and that they come from the other modules. 12:00:57 Steven: You can list pruning step as done but not say anything about how in that module. 12:00:59 John: ... 12:01:01 Steven: It's like bind; if you have no binds there is no bind processing. 12:01:03 Erik: We have markup associated with processing and validation on submission. 12:01:05 John: Not readonly. 12:01:09 Erik: readonly could be enforced by the data module. Or it would wrap it. 12:01:11 Leigh: We don't have interfaces so we don't have a place to say it, but we should make sure that you can initialize an instance with readonly data. 12:01:14 John: It's done in replace, but we don't have an interface for replace. 12:01:16 Charlie: Why is readonly done in the data module? 12:01:18 Nick: ... 12:01:20 John: The readonly module only has the bind attribute and a few throws in other modules. 12:01:22 Charlie: I would say readonly from the logic module injects it into the data module. 12:01:24 Nick: Or do you want to make it more pluggable that we add something to the data layer that supports it; the we have to specify it. 12:01:27 Charlie: The attribute is in the logic layer. 12:01:29 John: I don't want to take out the Note about replace with the readonly node. 12:01:31 Leigh: That's what I asked; where do we say this? 12:01:33 Charlie: In the driver. 12:01:35 Leigh: I wonder if we could specify it in IDL without datatypes, just using IDs. 12:01:39 Nick: I don't see the advantages. 12:01:41 Leigh: A place to specify the behavior. 12:01:43 Erik: It's too specific to implementation. 12:01:45 John: So use object as types? 12:01:47 Leigh: And id. Just use it as pseudocode. 12:01:49 Erik: But it looks like an API and it wouldn't be good. 12:01:51 Leigh: It's pseudocode. 12:01:53 Erik: I'm wondering how much of this matters. 12:01:55 Leigh: The question is, what do we write in the four pigeonholes in submission? 12:01:57 Nick: So we just want a more formal spec. 12:01:59 John: That never happened because there were only two levels: completely formal, and what we have now. The argument now is that in the interest of incremental adoption we need to go up another level but not be completely formal with IDL. So we'll divide into modules and use prose. 12:02:03 Nick: When you start to define interfaces and functions and callbacks, then there's no advantages. 12:02:05 John: We won't say it's all required; now we have to say what to do when pieces aren't required. So we're writing a more relaxed conformance section. 12:02:10 Nick: I don't see the benefit of IDL. 12:02:12 John: I'd like to see IDL but we don't have critical mass to go there. 12:02:14 Nick: I misunderstood. 12:02:16 John: We'll have a read-only module that will say "I will add to the bind element a readonly attribute" and "I will have certain effects on the instance module and the submission module." 12:02:19 Leigh: So there will be named steps in instance and submission where we say "other modules may introduce effects here." 12:02:22 John: Yes. 12:02:24 topic: Validation Module 12:02:26 John: So do we have a validation module. Or do we lump it all together since that's what we have in XForms 1.1? 12:02:29 Uli: I don't like a module for validation. 12:02:31 Raphael: So how to do we define XForms Basic in terms of modules. 12:02:33 Steven: The syntax is exactly the same; it's just in English text. The documents are identical. 12:02:35 Raphael: The is only for basic types. 12:02:39 Nick: We could split up the validation module into more parts. 12:02:41 John: It's two implementations of the validation module. 12:02:43 Uli: In 1.1 we have the model-only level of conformance, with no UI. 12:02:45 John: That's the first nod to model. 12:02:47 Nick: So it doesn't have all the UI modules. 12:02:49 Charlie: I'm a little queasy about the schema for the AJAX thing. Can we have bind constraint and type not required and upgrade from SHOULD to MUST? 12:02:52 John: What do we return from property level when you have a couple of modules? 12:02:54 Charlie: An array? 12:02:56 Leigh: Or ask about each module. 12:02:58 Charlie: So I guess I want the schema require and the rest not. 12:03:00 John: calculate is not hard in JavaScript but Schema might be. 12:03:02 Charlie: So they're all optional. Hmmm... 12:03:04 John: Do we need a separate module for the schema. 12:03:06 Leigh: XForms Basic gives you schema type libraries, not just fixed types. 12:03:10 John: We could have the basic module have the listed types only, and then have a separate module for schema data types. 12:03:13 Erik: We can always split it up later. 12:03:15 John: It seems not much effort to split up now. People can implement validation without schema. 12:03:17 Leigh: RNG has two data types, string and token. The rest come from a data type library and you can use XML Schema Part 2, or something else implementation-specific. 12:03:20 John: The current state is that the type MIP is in the validation module along with constraint and required. We haven't decided yet about the rest. There is a separate XML Schema validation module with @schema, xsi:type, inline xsd:schema, and full Schema structural validation. 12:03:24 Leigh: So that would imply type is either undefined without the Schema module, or it's XML Schema. 12:03:26 John: Or XML schema types. 12:03:28 topic: Lunch 12:26:13 Topic: Type Attribute 12:26:13 John: So the question at hand is whether the type attribute is defined or if it is left open and typed elsewhere. 12:26:13 Charlie: How does this work with JavaScript? 12:26:15 Leigh: The driver defines it. 12:26:17 Leigh: RNG seems to define token and string, and leave the rest to libraries. 12:26:19 John: What if you have no types? 12:26:21 Leigh: Then you just get string. 12:26:23 John: So add a module that just defines the XForms types. 12:26:25 Leigh: I don't see that as useful. 12:26:27 Erik: It can be. 12:26:29 Charlie: Having Javascript types would be useful, but it's also useful to have an onramp to XML Schema types. 12:26:31 Leigh: OK. 12:26:33 John: We say that @type value is in the default namespace, not the XForms namespace. 12:26:47 John: So we have agreed that it's OK to have a separate type module with just the XForms version of the XML Schema types. 12:26:47 Leigh: I don't think it's harmful, just might not be worth the work. 12:27:04 John: Hopefully it's just a section divider. 12:38:54 John: So here's the model module. 12:38:54 John: But that means we need to have bind content model open? 12:38:54 Leigh: No, it uses an attributegroup and modules add up to it. 12:38:54 John: So if you don't implement p3ptype you can still accept the documents? 12:38:54 Leigh: That would be if you subsetted XForms, so don't do that. This is for adding modules into non-XForms documents. 12:38:56 John: So I guess it's OK if you don't validate. 12:45:51 Steven: Are you sure? 12:45:51 John: I'm not sure then. 12:45:51 Leigh: Drivers validate, not people. 12:45:51 Steven: Modularization is for language authors, not form authors. 12:45:57 Leigh: This is why Raman wanted to make sure there were no document type differences between XForms Full and XForms Basic. If you want to create a version of XForms that doesn't implement some of the features, it won't load full XForms documents. The modularity is for adding bits of XForms to Dojo, for example. 12:46:48 topic: Submission Module 12:51:31 Nick: The submission module needs to refer to the other modules. 12:51:31 John: The submission material is nicely contained. Put the validation behavior here, relevance pruning here, etc. 12:51:31 Charlie: I'd still prefer that we could express submission without referring to those concepts and have the driver do that. 12:51:31 John: Other than duplicating the table, I don't know what to do. I renamed "Minimal Content Model" to "Overview of Attributes." I think we had last-call comments that those were confusing, but we could change them back. 12:53:37 Charlie: What's the minimal set we feel we need? 12:53:37 John: In the special attributes section contains the detailed information of what's required. There are precious few. 12:53:37 Nick: I changed the structure of that module. I created 11.1 Common Submission Attributes and put them all in a group, so I can refer to it from several places. 12:53:37 John: That makes sense. But as it was, it has all the attributes and all the elements. 11.2 has xforms-submit-event definition. 12:55:47 John: If we have an action module that defines deferred-update behavior, or a data module, then step 2 has to identify the data. 12:55:47 Charlie: Maybe you could in some lightweight way point it at some string. 12:55:47 John: Then you wouldn't need ref. 12:55:47 Charlie: That's what I was thinking of. 12:55:47 John: And replace and target. If you just want to submit and get the data back. We say the default is replace="all". 12:58:23 John: We seem to be missing an event for submission-result-received and we should add that to 1.2. 12:58:23 Charlie: You could grab the result and not have replace. 12:58:23 John: Even so, we have a list of 9 steps for the results of XForms submit; we have a jumping-off point for asynchronous. It comes back, but it's not using an event to do that. 12:58:23 Charlie: Yes. Detaching this from the data module would be a good exercise. Then we add data, then we add model, then validation. 12:58:24 John: The relevant module might be the thing that adds the relevant to submission. 13:05:41 Nick: You need to put a hook here. 13:05:41 Leigh: That's why I proposed IDL. The submission module invokes a function via IDL and the relevance module redefines the function. 13:05:41 Nick: That's too formal. 13:05:41 Charlie: It's mixins and aspects but in prose. 13:05:41 Leigh: But we are planning to put in hooks. 13:05:43 Charlie: We won't get the hooks right. 13:07:55 Charlie: We have a subset of steps in the submission document. The driver adds the additional steps in those numbers. It's not readable, I agree, but it's not a problem writing it. 13:07:55 John: You pull in relevance and readonly and then what? 13:07:55 Charlie: In the driver. 13:07:55 John: Then we have to write all combinations? 13:07:55 Leigh: No, we write one combination. 13:07:57 John: That makes the driver complicated. 13:07:59 Charlie: Yes. 13:08:49 Steven has left #forms 13:09:07 Steven has joined #forms 13:09:49 Erik: So it's supposed to be for implementers. 13:09:49 John: There comes a point where it's hard to read the spec even for implementers. 13:10:46 John: Maybe some notes? 13:10:46 Charlie: So it smells slightly of non-orthogonality but maybe it's the right compromise. 13:10:46 John: And so others may add to it but it's harder. 13:27:28 unl has joined #forms 13:28:04 Charlie: We need to have a note that says these are there for cases where you have them. 13:28:04 * Break 13:29:57 unbreak 13:32:41 http://www.w3.org/2005/10/Process-20051014/process.html#correction-classes 13:41:03 I had a quick look at XML Base SE. The only thing I noticed is that the value of the xml:base attribute is interpreted as a Legacy Extended IRI (LEIRI). The characters allowed in a LEIRI include %x0-1F which aren't all allowed in XML 1.0, maybe a note to point out that xml:base doesn't supports all Legacy Extended IRIs but only a subset would be welcome. 13:42:30 Seems like there should at least be a note to point out that consuming applications of the new xml base edition might have failures in attributes expecting only URIs unless the application language is rev'd to both include this new version of base AND upgrade all URIs to IRIs at the same time. 13:44:07 scribe ebruchez 13:44:15 scribe: ebruchez 13:44:20 It is also not clear from their spec about what is allowed to be considered a URI in a host language 13:44:59 It would be nice to have an example of an xml:base with an actual IRI init 13:45:02 Topic: Submission module 13:45:08 s/init/in it/ 13:49:22 John: Looking at Commons attribute for submission. Where to @ref and @bind go? Separate module? 13:50:11 Erik: What did people have in mind when talking about using the submission module independently? How is the data passed to the submission? 13:50:57 Charlie: I think the attributes come from the XForms "driver" which puts the XForms modules together. 13:51:36 Charlie: Whoever wants to use modules together must specify how they work together. 13:52:19 John: So it wouldn't the relevant module adding @relevant, for example, but a combinator for the relevant and submission modules. 13:53:04 Erik: Is it a "driver" or a "combinator"? 13:53:43 John: Driver doesn't tell me much. Prefer "aggregator". 13:53:51 Charlie: ... 13:54:21 John: How many aggregator modules do we need for XForms 1.1 then? 13:54:42 Erik: Couldn't this be done by the model module? 13:55:25 John: No, model has more stuff. 13:56:00 Leigh: Model could define @ref and @bind. 13:56:24 John: ... 13:56:40 Charlie: Streamlined syntax allows controls without model. 13:56:50 Leigh: Depends whether there is an implicit model or not. 13:57:18 Erik: Why can't we have a single "aggregator" for XForms 1.1? 13:58:33 Charlie: ... 13:59:29 John: Could have subsections in XForms 1.1, e.g. how to combine data and model modules, how to combine submission and data modules, etc. 14:02:46 John: Next down are attributes clearly related to submission: @resources, @action, etc. What about serialization? 14:04:48 Indeed 14:06:40 John: @replace: is it extensible? 14:09:07 Erik: Funny to me to take bout @replace and @target out of submission and put them in the aggregator. How would you use just submission in HTML then? 14:09:22 John: Through an event, e.g. xforms-submission-received. 14:12:32 John: action should go in too. 14:13:31 Uli: What about ? It will be in XML Events 2.0. 14:13:48 John: Generic, will go to other module in the meanwhile. 14:15:45 John: will go with UI, but it also applies to container controls. 14:15:47 Erik: Does it? 14:15:58 John: Yes, focus on group or repeat is possible, will then select first relevant control. 14:21:06 John: (For a moment, let's work individually on our action items.) 14:28:35 Erik: Regarding my action item http://www.w3.org/2007/09/19-forms-minutes.html#action02, I think this is now addressed in the 1.1 spec: "If any of the stored values or subtree copies do not correspond to an item with a matching storage value or subtree, the form control must indicate an out-of-range condition." 14:50:19 klotz has joined #forms 14:50:24 Selects any form control that is relevant or non-relevant (respectively) or bound to a node with the model item property relevant evaluating to true or false (respectively). 14:50:24 14:50:41

Form controls are considered to be non-relevant if any of the following apply:

15:33:40 wellsk has left #forms