06:55:19 <RRSAgent> RRSAgent has joined #forms
06:55:19 <RRSAgent> logging to http://www.w3.org/2008/10/21-forms-irc
06:55:25 <John_Boyer> zakim, this will be forms
06:55:25 <Zakim> ok, John_Boyer, I see HTML_Forms()3:00AM already started
06:55:31 <John_Boyer> rrsagent, make log public
06:55:41 <unl> unl has joined #forms
06:57:03 <Zakim> +John_Boyer
06:57:04 <Zakim> -John_Boyer
06:57:04 <Zakim> +John_Boyer
07:00:06 <John_Boyer> Agenda: http://lists.w3.org/Archives/Public/public-forms/2008Oct/0035.html
07:02:05 <Steven> Steven has joined #forms
07:02:24 <John_Boyer> Meeting: Cannes Face-to-Face , Oct. 21, 2008
07:02:45 <John_Boyer> Chair: John
07:02:54 <Steven> Scribe: Steven
07:03:10 <Steven> rrsagent, make minutes
07:03:10 <RRSAgent> I have made the request to generate http://www.w3.org/2008/10/21-forms-minutes.html Steven
07:03:30 <Steven> Previous: http://www.w3.org/2008/10/20-forms-minutes
07:04:25 <Steven> rrsagent, make log public
07:04:32 <Steven> rrsagent, make minutes
07:04:32 <RRSAgent> I have made the request to generate http://www.w3.org/2008/10/21-forms-minutes.html Steven
07:05:31 <Steven> Present: Charlie, Raman, Nick, Steven, Uli, John(Remote)
07:07:39 <Steven> Topic: User Interface Layer Module
07:07:52 <Steven> rrsagent, make minutes
07:07:52 <RRSAgent> I have made the request to generate http://www.w3.org/2008/10/21-forms-minutes.html Steven
07:08:34 <wellsk> wellsk has joined #forms
07:09:08 <Zakim> +wellsk
07:09:13 <John_Boyer> http://www.w3.org/MarkUp/Forms/wiki/XForms_1.2_Modularization
07:09:22 <Steven> Present+Keith(remote)
07:11:08 <Steven> John: There are a number of submosules
07:11:24 <Steven> ... we haven't discussed this module so much
07:11:47 <Steven> s/much/much yet/
07:11:59 <Steven> John: Looking at first bullet
07:12:07 <Steven> ... forms controls
07:12:31 <Steven> ... defines UI binding
07:13:06 <Steven> Steven: SO it defines the generic things you find over all controls
07:13:16 <Steven> John: Yes, like chapter 8 of XForms now
07:13:32 <Steven> ... look at the beginning of chapter 8
07:13:59 <Steven> ... applies to ordnary controls, but also group and switch
07:14:37 <Steven> ... this module is the home for setfocus; I wouldn't know where else to put it
07:15:21 <Steven> ... also where we have defined refresh
07:15:31 <Steven> ... the model doesn;t have refresh until you get here
07:16:33 <Steven> Steven; So if you had a language with a model but no controld, you wouldn't need refresh?
07:16:36 <Steven> John: Yes
07:16:53 <unl> s/controld/controls
07:17:26 <Steven> ... the UI bindings are not distinguishable from other use of bindings syntactically, only semantically
07:19:47 <Steven> ... and that can be seen as a problem
07:20:01 <Steven> ... which we haven't had in the past
07:21:09 <Steven> ... someone else's custom elements can't get the refresh behaviour just by using the binding module for instance
07:21:21 <Steven> ... they have to do something else as well
07:22:10 <Steven> Steven: Well, it's a problem from the language designers viewpoint, but not from an author's viewpoint
07:22:33 <Steven> John: Well, the author can't see from the use of the attribute whether you get relevance for instance
07:22:53 <Roger> Roger has joined #forms
07:23:09 <Steven> Present+Rogelio(remote)
07:24:29 <Steven> Steven: So there is no way for a custom element to say which of the bindings it needs
07:24:34 <Steven> John: And which should be the default
07:24:53 <Steven> ... message, hint, alert, label, filename, mediatype
07:25:10 <Steven> ... all use ref, neither as an action nor as a UI binding
07:25:37 <Steven> ... so what does ref do on <label>?
07:25:53 <Steven> ... and when you ref a nonrelevant node?
07:26:24 <Steven> ... and message still hapens as an action, even if the thing that is ref'd is nonrelevant
07:26:53 <Steven> Steven: Interesting
07:27:27 <Steven> John: SO what should we expect for edge cases with elements like help hint and alert
07:27:32 <Steven> s/SO/So/
07:27:47 <Steven> s/altert/alert?/
07:27:55 <Steven> Nick: Never tried it
07:28:46 <Steven> Steven: My git feeling is that you would expect it not to work
07:28:57 <Steven> ... nonrelevant means that the data isn't useful in the current state
07:29:08 <Steven> s/git/gut/
07:29:23 <Steven> John: So Keith, how about the test set? DO we test that?
07:29:35 <Steven> Keith: I'd have to check
07:30:22 <Steven> ACTION: Keith to investigate if we test relevance on elements like help hint and alert
07:30:23 <trackbot> Created ACTION-496 - Investigate if we test relevance on elements like help hint and alert [on Keith Wells - due 2008-10-28].
07:32:05 <Steven> John: Should this be a clarification on XForms 1.1
07:33:10 <Steven> John: DOes anybody agree with Steven's gut feeling above?
07:33:14 <Steven> s/DO/Do/
07:33:40 <Steven> Charlie: It seems to be consistent, and therefore makes modularization easier
07:33:54 <Steven> John: Mark would regard ref on help etc as a UI binding
07:37:03 <Steven> John: An interesting side of that, which means that labels get notification events, is that XML Events 2 distinguishes target and bubble
07:37:25 <Steven> ... and so phase=default is the wrong default for XML Events 2
07:37:44 <Steven> ... the proper default phase should be target
07:37:53 <Steven> Steven: WHat? No!
07:37:57 <Steven> s/WH/Wh/
07:41:14 <Steven> John: The problem is that things like value change events on child events like alert under an input control will bubble up, and you don't want to listen to those while waiting for a value change on the control
07:42:49 <Steven> ... or otherwise not treat ref on an alert etc as a UI control
07:43:35 <Steven> John: It is difficult to identify when a binding is meant to be a UI binding otherwise
07:44:57 <Steven> John: Part of the problem of extending UI binding beyond our elements is that it introduces this problem
07:46:08 <Steven> John: SO we could have a different set of attributes that distinguishes them
07:46:18 <Steven> Charlie: Not thrilled with that
07:46:26 <Steven> s/SO/So/
07:48:39 <Steven> Charlie: You could have a meta attribute that encodes the difference
07:48:59 <Steven> Uli: Not much better
07:49:22 <Steven> ... I'm fine with reusing ref
07:49:39 <Steven> Charlie: How do you distinguish?
07:50:36 <Steven> John: What poer does the driver author have?
07:50:50 <unl> s/poer/power
07:53:05 <Steven> Steven: SO why not different modules, where the attributes are spelled the same, but have different semantics
07:53:45 <unl> s/SO/So
07:53:59 <Steven> ... so the UI bindings are spelled "ref", and the message bindings are also spelled "ref" but they have different semantics
07:55:03 <Steven> ... so the syntax is the same, and the semantics are different
07:58:04 <Steven> John: But how do the modules themselves introspect and work out which is which
07:59:06 <Steven> Steven: Oh I see your problem. If the bindings are implemented by a bit of scriupt that has to walk the tree
07:59:17 <Steven> s/iupt/ipt
08:00:59 <Steven> Steven: Doesn't this mean that there has to be an initial walk of the tree, disambiguating the attributes before processing proper starts?
08:01:41 <Steven> ... otherwise all attributes would have to be lexiacally unique
08:01:52 <Steven> ... and we can't guarantee that in a compound document
08:04:15 <Steven> Uli: This is too generic
08:08:31 <Steven> John: How come this never happened before?
08:08:54 <Steven> Steven: In XHTML, the only attribute with the same name and different meanings is @name
08:09:05 <Steven> ... and we have renamed that mostly
08:09:34 <Steven> ... (I can't think of another attribute with this property offhand)
08:09:40 <John_Boyer> i.e. is it a new thing that we have, in one language module profile, multiple implementations for the same attr and the problem of needing to choose one based on context
08:09:58 <John_Boyer> and if so, what provides the mapping from context to implementation?
08:10:29 <Steven> John: Should we have different names for the different binding types? Seems harsh
08:11:02 <John_Boyer> maybe css decoration
08:12:34 <Steven> Steven: THat's what I meant by an initial walk of the tree
08:12:49 <Steven> ... different classes of elements can have a different secret attribute to identify it
08:13:24 <Roland_> Roland_ has joined #forms
08:13:47 <Steven> present+Roland(remote)
08:13:55 <Steven> rrsagent, make minutes
08:13:55 <RRSAgent> I have made the request to generate http://www.w3.org/2008/10/21-forms-minutes.html Steven
08:14:58 <Steven> Chalrie: That's what I meant by a meta attribute earlier
08:15:40 <Steven> s/rl/lr/
08:15:44 <Steven> s/SO/So/
08:16:25 <Steven> John: We can use implied attributes at the schema level
08:16:49 <Steven> Charlie: That leads to complexity
08:18:00 <Steven> ... and a steep learning curve
08:18:41 <Steven> Steven: You think that it is easier to understand if you had <input uiref=...  and <alert msgref="" ?
08:18:47 <Steven> Charlie: Yes
08:19:09 <markbirbeck> markbirbeck has joined #forms
08:19:14 <Steven> Steven: I'm not sure. I think the user can deal with different effects on different elements
08:19:23 <Steven> Present+MarkB(remote)
08:19:33 <markbirbeck> Very remote...
08:22:58 <Steven> rrsagent, make minutes
08:22:58 <RRSAgent> I have made the request to generate http://www.w3.org/2008/10/21-forms-minutes.html Steven
08:23:28 <Steven> John: It seems reasonable to leave this design as is, where UI binding is generically applicable
08:23:41 <Steven> ... and there are things that inherit UI bindings, and things that don't
08:24:08 <Steven> ... but do we need that third class of binding, where you are inheriting relevance but not events?
08:25:17 <Steven> ... or do we need to look at the meta-level where we say that the binding ijust for data, or data+relevance, ...
08:26:14 <Steven> Steven: Do we need to distinguish the first node rule?
08:26:27 <Steven> John: No we have a different attribute where that kicks in
08:26:37 <wellsk> no objection
08:26:52 <Steven> John: Are we OK with help hint and alert being a data binding only (no events, and no relevance etc)
08:26:55 <Steven> Charlie: OK
08:27:13 <Steven> STeven: Relevance gets ignored
08:27:15 <Steven> John: Yes
08:29:51 <Zakim> -wellsk
08:30:27 <Zakim> -John_Boyer
08:30:29 <Zakim> -Cannes
08:30:29 <Zakim> HTML_Forms()3:00AM has ended
08:30:30 <Zakim> Attendees were Cannes, John_Boyer, wellsk
08:30:39 <Steven> rrsagent, make minutes
08:30:39 <RRSAgent> I have made the request to generate http://www.w3.org/2008/10/21-forms-minutes.html Steven
08:31:34 <John_Boyer> summary is that, for now, we stick to having just the two fundamental types of bindings, data and UI.
08:32:21 <John_Boyer> We define that UI bindings are applied to all the things we currently claim are form controls (input, select1, ..., group, switch)
08:33:04 <John_Boyer> We define that other uses of bindings on our current set of modules are data bindings (submission, setvalue, message, label, help, hint alert)
08:34:05 <John_Boyer> and finally, we say that authors of future modules have various mechanisms in their repertoire (prose, schema attribute group usage, css decoration) for indicating which kind of binding is applicable to their new element
08:34:40 <John_Boyer> rrsagent, make minutes
08:34:41 <RRSAgent> I have made the request to generate http://www.w3.org/2008/10/21-forms-minutes.html John_Boyer
08:58:30 <Zakim> HTML_Forms()3:00AM has now started
08:58:32 <Zakim> +wellsk
09:01:14 <Zakim> +Cannes
09:01:16 <Zakim> -Cannes
09:01:16 <Zakim> +Cannes
09:02:00 <Charlie> Charlie has joined #forms
09:02:45 <Charlie> zakim, who is here?
09:02:45 <Zakim> On the phone I see wellsk, Cannes
09:02:46 <Zakim> On IRC I see Charlie, markbirbeck, Roger, wellsk, RRSAgent, John_Boyer, Zakim, trackbot
09:03:32 <Zakim> +John_Boyer
09:06:03 <Charlie> Scribe: Charlie
09:06:45 <unl> unl has joined #forms
09:11:14 <Steven> Steven has joined #forms
09:16:08 <nick> nick has joined #forms
09:16:15 <Charlie> Topic: UI specs (cont)
09:20:57 <Charlie> John: thought it good to separate "output" control from the others
09:21:02 <Charlie> seems like a different beast
09:21:29 <Charlie> UI binding on an output is a little different from the others -- only goes in one direction
09:21:40 <Charlie> Steven: yes, but isn't this just a detail?
09:21:44 <Charlie> no way to go in the other way given it's output
09:21:51 <Charlie> if it was 2-way you'd not notice
09:22:02 <Charlie> for example this is really a "read-only" input
09:22:11 <Charlie> John: historicall, R/O comes from data not control
09:22:21 <Charlie> Steven: yes, but behavior is similar/same
09:22:49 <Charlie> Raman: other difference is in business workflow -- r/o to you but writable to mgr, then semantics are different
09:23:08 <Charlie> but wouldn't lose output control for this reason
09:23:42 <Charlie> John: assume then that UI binding on output -- still register for value-change events?
09:23:47 <Charlie> Steven: would hope so, yes
09:24:04 <Charlie> John: and other notification events, yes
09:24:53 <Charlie> inputs are directly manipulable by end-user vs container controls have NSB but don't directly manipulate the data
09:25:24 <Charlie> John: where should trigger go?  another output?
09:25:47 <Charlie> it doesn't manipulate the data
09:25:51 <Charlie> fires events
09:27:44 <Charlie> Charlie: not convinced it's part of the output category
09:28:14 <Charlie> John: so which module should it go in?  there's trigger and submit
09:29:37 <Charlie> perhaps a third bucket for trigger and submit
09:29:53 <Charlie> though submit is problematic -- unless you're using the submission module do you need submit?
09:30:14 <Charlie> so separate trigger and submit modules
09:30:17 <Charlie> Steven: ok
09:30:35 <Charlie> we can put modules in one spec, i.e. submission and triggering together
09:31:06 <Charlie> John: might be easier to put trigger in with the other input controls
09:31:13 <Charlie> but submit needs the submission module
09:31:38 <Charlie> but perhaps we don't care if the object of the event is really a submission module
09:31:51 <markbirbeck> Probably missed the discussion here. :) But I agree with JB that output is 'different'. An XForms that contains *only* model, instance and ouput, can be regarded as in 'inside-out' XSLT transformation. It can be processed 'one-way', with the result being a static page. I think there are many use-cases for that, and it's something worth documenting. (For a lot of scenarios you no longer require the usual data+XSLT-> static page, because you can throw th
09:34:06 <Charlie> Mark -- did your text get truncated?
09:36:35 <Charlie> John: what about the label module?
09:37:14 <Charlie> labeling is useful apart from whether there are form controls at all
09:37:22 <Charlie> e.g. for group module
09:37:54 <Charlie> seems like all of the other controls require label
09:37:58 <Charlie> Charlie: require?
09:38:21 <Charlie> benefit from yes, but not require
09:39:14 <Charlie> for accessibility we do require label in input now
09:39:25 <Charlie> so in fact the input module does now require the label
09:39:53 <Charlie> John: suppose we have the label module and an additional attribute @for
09:39:58 <Charlie> Raman: as in HTML4
09:40:09 <Charlie> John: so we're still semantically requiring that an input be labeled
09:41:18 <Charlie> Steven: input module doesn't have to require that there be a label
09:41:37 <Charlie> John: as in the driver?
09:41:39 <Charlie> all: yes
09:42:04 <Charlie> Raman: so what about hint, help, etc
09:43:29 <Charlie> John: even if it's optional, my processor would need to know about it to support it when it does appear
09:46:00 <Charlie> Steven: the input control has non-relevant and CSS picks this up and propagates to label
09:46:17 <Charlie> John: label gets this from containing form control, via css, but there still is this relationahip
09:46:29 <Charlie> s/relationalhip/relationship
09:46:40 <Charlie> Steven: but *label* doesn't have non-relevant it's the containing thing
09:47:14 <Charlie> Raman: if label isn't nested then this is problematic
09:47:31 <Charlie> Many: containment of labels in controls is helpful
09:48:48 <Charlie> John: regardless of how the label is specified, do we still say that the associated control drives the label visibility?
09:49:34 <Charlie> Raman: if not nested then the association can still be preserved through css pseudo-classes
09:49:48 <Charlie> Raman: also will get into complex layout issues
09:50:35 <Charlie> John: i'm trying to tease apart syntax from conceptual dependencies
09:51:15 <Charlie> seems to be a property of label and not the control modules to know how to behave
09:51:24 <Charlie> i.e. to capture the relationship
09:51:40 <Charlie> Uli: would even say the label module doesn't need this intelligence
09:51:45 <Charlie> just stick with containment
09:52:22 <Charlie> don't need extra intelligence for label, except perhaps when importing label into another module
09:53:17 <Charlie> especially label doesn't need to know about relevance etc
09:53:46 <Charlie> John: so the xforms driver therefore that puts alert help hint inside form controls?
09:54:32 <Charlie> John: in the past have looked at label and hint as control metadata -- info available to the control 
09:55:01 <Charlie> John: having trouble with the idea that input control doesn't know about its nested elements
09:55:47 <Charlie> Steven: yes, but how does the input control act differently depending on whether it has a label or not?
10:00:24 <Charlie> Steven: behavior is as-if CSS styles are controlling this linkage
10:00:33 <Charlie> John: where does it say in the spec that this is the mechanism/meaning?
10:00:58 <Charlie> Raman: in my recollection we have said it behaves "as-if" there were CSS processing -- to not specify layout
10:01:05 <Charlie> John: no, we've said there is no requirement for CSS
10:01:18 <Charlie> Raman: right, but behavior is "as if" such behavior is available
10:01:27 <Charlie> John: we don't say "as if" CSS
10:01:50 <Charlie> Steven: abstract says we separate presentation from content
10:01:58 <Charlie> Steven: means for me controls are not doing presentation
10:02:39 <Charlie> John: what questions can i ask of a form control?  what is your hint, alert?
10:02:54 <Charlie> Raman: we never defined that object model or signatures on the controls in the spec -- not an IDL
10:03:15 <Charlie> John: except that we say input requires a label
10:03:21 <Charlie> Steven: that's syntactic 
10:03:44 <Charlie> John: yes, but given this requirement it's reasonable to say that form controls have the following features
10:03:54 <Charlie> Raman: yes, when it's a monolithic spec not with modules
10:04:12 <Charlie> John: ok, now we're trying to decide how to put things together again
10:04:36 <Charlie> John: again it's the xforms driver module that puts the original meaning of xforms back together
10:04:53 <Charlie> does it have to say that labels are used with form controls?
10:06:19 <Charlie> Steven: so yes, we'd say that xforms controls not including output are required to have labels
10:06:34 <Charlie> Steven: Mark would point out that label could also be used in other contexts
10:06:52 <markbirbeck> I would like to point out that labels could be used in other contexts. :)
10:07:47 <Steven> WHich is just what I said live here
10:08:03 <markbirbeck> That's why I said it!
10:08:10 <markbirbeck> I wrote it immediately after your comment.
10:08:15 <Steven> 1. Labels can be used all over the place. Labels can label tables, images, and so on
10:08:19 <unl> s/WHich/Which
10:08:29 <markbirbeck> You said "Mark would point that..." so I did. :)
10:08:31 <Steven> 2. Ther eis nothing semantically wrong with an input that doesn't have a label
10:08:45 <nick> zakim, who is on the phone?
10:08:45 <Zakim> On the phone I see wellsk, Cannes, John_Boyer
10:08:49 <Steven> you could have a language with a single control
10:08:57 <Steven> and it might not need to be labeled
10:09:17 <markbirbeck> When you create a control out of other controls, you often have controls with no label.
10:09:22 <Steven> We require labels on controls (except for output) for a *syntactic* reason, not a semantic
10:09:23 <Steven> one
10:09:51 <Steven> +1 to mark
10:09:56 <markbirbeck> The standard example being an IP input control, that is actually comprise of four input controls.
10:10:06 <Steven> there you go
10:10:19 <markbirbeck> So if we want to 'recursively' use XForms in this way, we need to relax things 'at some point'.
10:10:20 <Steven> So label is not an intrinsic part of a control
10:10:28 <Steven> it is extrinsic
10:10:41 <Charlie> but are those xforms controls or managed controls in the scope of a parent binding?
10:11:00 <markbirbeck> Some higher-level language could impose that restriction, though.
10:11:09 <John_Boyer> but the argument being made here is that in the XForms driver module, the label will be syntactically required by input elements (e.g. each of the four (or six) IP address inputs)
10:11:10 <markbirbeck> I.e., that a control must have a label.
10:11:19 <Charlie> perhaps they have local data binding to the state managed by their parent control not the root data model
10:11:32 <unl> @mark: an IP control could be done in another way: use an appropriate datatype, just like xs:dateTime
10:11:35 <Charlie> in the IP compund control case
10:11:38 <markbirbeck> Yes JB, and the problem with that is that you end up using <label /> everywhere.
10:11:49 <markbirbeck> Kind of defeats the object of enforcing it.
10:12:29 <markbirbeck> @unl: No...I'm talking about using XForms in something like XBL, to define custom controls that are then bound.
10:12:46 <raman> raman has joined #forms
10:12:49 <markbirbeck> @unl: You are right that you might use a datatype to instigate the binding, but that doesn't *define* what to bind.
10:13:20 <raman> I must be jetlagged, for the last 10 minutes I have been busily joining the #xforms channel and wondering why  I cant hear anyone.
10:14:20 <unl> @mark: see your point, but where's the difference to a date input control? could be done with three inputs, too.
10:15:51 <Charlie> John: so within a particular document the xforms driver module will only require label inside inputs in some context?
10:16:04 <Charlie> how can it decide when they're required and when not, as in the IP control case?
10:16:22 <Charlie> Steven: but the restriction that a control has a label is syntactical not semantic
10:16:29 <markbirbeck> Actually...I'm going to back-track. :)
10:16:43 <Charlie> Steven: so a different module can make a different decision -- e.g. the IP control
10:17:04 <markbirbeck> I'd like to hear from Raman how the IP control should behave in a voice system.
10:17:16 <markbirbeck> Should he get a voice-prompt on each of the four controls?
10:17:31 <Charlie> John: how can the driver tell the difference between these two cases?
10:17:33 <markbirbeck> If so, then we should be using CSS to hide the label, rather than removing it.
10:17:55 <markbirbeck> (For the visual use-case, I mean.)
10:18:10 <Charlie> at some point the labels and ARIA properties merge
10:18:23 <Charlie> perhaps the IP subfields need ARIA properties not labels
10:18:53 <markbirbeck> @Charlie: What does Raman think about that? I.e., should each field have a label?
10:20:35 <Charlie> raman says a label at the group level but not subfields is ok
10:20:42 <Charlie> and they probably don't need aria properties
10:21:17 <Charlie> Raman: some get filled in automatically and the individual meaning is not obvious of the separate subfields
10:22:01 <Charlie> designer of the IP subcontrols should have the freedom to put the label on the composite not subfields
10:22:10 <Charlie> John: ok, suppose the internal xforms inputs do not have labels
10:22:22 <Charlie> John: outside of that IP composite field have another input control
10:22:48 <Charlie> are we saying that this individual can't use the xforms driver since it will say *all* input controls require labels?
10:23:01 <Roland_> Roland_ has joined #forms
10:23:21 <Charlie> Raman: IP wizard probably doesn't materialize input controls in the parent document
10:24:08 <John_Boyer> It seems like we have a system where xforms requires all inputs to have labels, but some other module can override that and say labels are not required on inputs.  But xf:input is then one element that has two contradictory schema definitions
10:24:16 <John_Boyer> one that requires a label and the other that doesn't
10:24:37 <John_Boyer> So if we compose xforms driver module + ip address editor module, then how do we validate documents under that composition?
10:25:00 <Charlie> Steven: all we're arguing about is whether our input module says it requires label?
10:26:04 <Charlie> John: don't think this mixing of policies for xf:input will work -- two definitions for the same element in the same namespace
10:26:23 <Charlie> Steven: can make it context dependent
10:26:41 <Charlie> Raman: think schema is a red-herring
10:26:45 <Charlie> for this problem
10:26:55 <Charlie> Mark's IP control doesn't belong in the xforms namespace
10:27:26 <Charlie> Raman: there's no contradiction
10:27:34 <Charlie> there's an xforms driver putting together the input and label
10:27:48 <Charlie> Raman: Mark has taken the lower level input element and built his control
10:28:10 <Charlie> John: there is still a contradiction since i have to build a tool that can tell the difference between these two uses of xf:input
10:29:00 <Charlie> Steven: if we were creating a driver that included the IP control we'd specify that content model
10:29:09 <Charlie> John: and the driver for xforms...
10:29:23 <Charlie> Steven: and we'd say that input otherwise is input, label, help, hint, alert
10:29:47 <Charlie> John: so if I want to override the xforms driver rules i can't use that driver
10:30:01 <Charlie> Steven: yes, you have to change the driver -- it's the top level
10:30:12 <Charlie> John: right, so you can't use the xforms driver
10:30:19 <Charlie> Raman: right it's a new custom language
10:31:12 <Charlie> Steven: we're defining the library, but the *main* is the driver
10:31:38 <Charlie> we have a variety of xhtml modules that do this now
10:31:57 <Charlie> John: do you have a situation where you're taking two large modules and composing them with contradictory rules on the *same* element?
10:32:16 <Charlie> seems like you're composing statements about complementary elements not the same
10:32:31 <Charlie> Steven: just requires context dependent syntax checking
10:34:17 <raman> xforms driver == main program tha tuses the various modules as libraries -- it's not a library  in its own right. John may be talking of a master xforms.a library that aggregates a set of modules --
10:34:26 <raman> that could be called the xforms 1.1 library.
10:35:07 <raman> but then since that lib doesn't contain custom controls, then you cannot write (and should not expect to) write a program that can use a custom control -- because the custom contol is not part of xforms 1.1
10:36:55 <Charlie> we need a "library" version of the xforms rules
10:37:14 <raman> and mark hasn't even said "hang on a minute"
10:37:23 <Charlie> i.e. a level below "main" that specifies the xforms rules so they can be composable with other extensions such as the IP custom control
10:37:33 <Charlie> break for lunch until 2:00 local time
10:37:37 <markbirbeck> I should also throw in that we have already shown in Ubiquity XForms that you can bind XForms functionality to an HTML input control. There there is *conceptually* the notion of an 'input' that is independent of any label, hint, alert or help. It seems awkward that we don't have that concept in XForms itself.
10:37:44 <Zakim> -wellsk
10:37:48 <Zakim> -John_Boyer
10:37:49 <Steven> rrsagent, make minutes
10:37:49 <RRSAgent> I have made the request to generate http://www.w3.org/2008/10/21-forms-minutes.html Steven
10:37:51 <markbirbeck> s/There there/That there/
10:38:41 <John_Boyer> yep, we buy that label is separate from input.  The problem I am flagging up is the fact that we're claiming the xforms driver will *require* label in *all* inputs
10:38:52 <John_Boyer> but the ip address module will then contradict that
10:39:30 <John_Boyer> so, if I want a language L ={xforms, ip address control}
10:39:48 <John_Boyer> then I have a language that contains two different and contradictory rules for xf:input
10:39:57 <John_Boyer> make sense?
10:40:08 <Zakim> -Cannes
10:40:09 <Zakim> HTML_Forms()3:00AM has ended
10:40:10 <Zakim> Attendees were wellsk, Cannes, John_Boyer
10:40:17 <John_Boyer> rrsagent, make minutes
10:40:17 <RRSAgent> I have made the request to generate http://www.w3.org/2008/10/21-forms-minutes.html John_Boyer
11:22:43 <markbirbeck> @JB Further to your argument, I wrote this earlier, but I think it was just after you disconnected:
11:22:46 <markbirbeck> "I should also throw in that we have already shown in Ubiquity XForms that you can bind XForms functionality to an HTML input control. There there is *conceptually* the notion of an 'input' that is independent of any label, hint, alert or help. It seems awkward that we don't have that concept in XForms itself."
11:40:47 <John_Boyer> @MB I agree that this would be the way to solve it in this specific case, though it flags up a general problem for modularization.
11:42:22 <John_Boyer> At the most specific level, I'm saying it seems hard to claim that "XForms" (i.e. the xforms driver module) requires label on xf:input when a custom control module author can make it optional.
11:42:40 <John_Boyer> It's an "unenforceable" requirements
11:43:00 <John_Boyer> One way to solve is to eliminate the requirement
11:45:29 <John_Boyer> But more generally, what is supposed to happen when module A makes claim A' about the schema of an element and module B makes claim B' about the same element.
11:45:54 <John_Boyer> Maybe its local elements versus global elements?
12:00:18 <Zakim> HTML_Forms()3:00AM has now started
12:00:25 <Zakim> +wellsk
12:02:31 <Zakim> +John_Boyer
12:08:33 <Zakim> +Cannes
12:08:44 <unl> unl has joined #forms
12:09:51 <nick> nick has joined #forms
12:09:59 <Charlie> Charlie has joined #forms
12:11:58 <nick> Scribe: nick
12:12:22 <Steven> Steven has joined #forms
12:13:00 <nick> TOPIC: Future meeting planning  
12:14:13 <Roland_> Roland_ has joined #forms
12:15:55 <John_Boyer> http://www.w3.org/MarkUp/Forms/wiki/FaceToFace
12:16:30 <nick> Steven: If HTML and Forms together we can do it twice
12:16:45 <nick> John: We expanded our meetings to 4 days
12:17:13 <nick> Nick: But steven needs to be in on Saterday
12:17:25 <nick> John: We only have two
12:17:32 <nick> Steven: That's fine
12:18:02 <nick> Raman: Hosting XHTML would be hard at google
12:18:15 <nick> Charlie: IBM is next door
12:20:27 <nick> Charlie: We need to make the Virtual days more formal
12:20:36 <nick> Roland: Maybe do 5 half days
12:21:03 <nick> Nick: Allocating time is more difficult for a virtual day
12:21:29 <nick> Charlie: I we do cont. 4 hours 
12:22:28 <nick> John: Unless we change our mind about FtF we don't have any virtual days
12:22:44 <nick> .. before the TP
12:23:33 <nick> John: California is OK
12:23:40 <nick> John: What about the UK one
12:24:14 <Steven> scribe: Steven
12:24:18 <John_Boyer> Right now it's also not virtual
12:24:24 <nick> nick has joined #forms
12:24:46 <Steven> scribe: Nick
12:24:51 <Steven> scribenick: nick
12:25:01 <Steven> scribenicknick: nick
12:25:13 <nick> John: What about 4 hours virtual meetings before the TP
12:25:25 <nick> (consensus)
12:26:14 <nick> John: Do we want to make a rough agenda for those meetings
12:26:43 <nick> Steven: Is Feb. to close, no it's fine
12:26:56 <nick> John: We will see how the modules go
12:27:28 <nick> TOPIC: The User Interface Layer specifications 
12:28:08 <nick> John: There is the issue with various models making statements about the same element
12:29:05 <nick> John: After you left MarkB mentioned that the XForms module will require the label to be required, as apposed to being optional
12:30:37 <nick> John: This solves this problem, but anybody can write a driver model that doesn't requires label inside an input
12:31:24 <nick> Steven: Then it isn't XForms anymore, but they may do it, we just want to provide models that they can use 'as' they want
12:31:40 <nick> John: Don't you believe in context based parsing
12:32:00 <nick> s/John:/Steven: John 
12:32:19 <nick> s/John:/Steven: John /
12:33:23 <nick> Steven: XHTML 1.1 requires you to specify DTD to specify the version, XHTML 2.0 uses a version attribute
12:33:50 <nick> Steven: You just check the document based on the version and pick up the right schema for the profile
12:34:31 <nick> Steven: Schema doesn't requires you to specify the schema in the document, the language can specify which schema to use
12:35:44 <nick> Raman: explains that a schema for a specific language can have local overides
12:36:32 <nick> Roland: The schema will include different modules the XForms language uses
12:37:24 <nick> Raman: Explains that we can create an aggregator XForms module that is used by the XForms driver
12:38:05 <nick> John: What is the difference between a module and a driver 
12:39:16 <nick> Steven: you can look at a driver as a  program and a module as a library, a library can reference other libraries
12:40:23 <Steven> doc= control*
12:40:24 <nick> Roland: One module can say that an input may have a label and another module can say that a label is required, the driver can choose then
12:40:41 <Steven> control=inputcontrol|ipcontrol
12:40:54 <markbirbeck> But why not simply have a module that contains all UI controls, unadorned?
12:40:56 <Steven> inputctrl=<input>label</input>
12:41:03 <markbirbeck> Then any language can import those.
12:41:18 <markbirbeck> For XForms we then add label, hint, help, etc.
12:41:27 <markbirbeck> I.e., we *insist* on label.
12:41:29 <John_Boyer> @MB: That solves this specific problem, yes
12:41:30 <Steven> ipctrl=<ip><input></input><input></input>label</ip>
12:41:42 <markbirbeck> But the question is simply, are we going to insist on all other languages also using label.
12:41:54 <markbirbeck> If we are, then fine...put label in the base module.
12:42:02 <Steven> label=<label></label>
12:42:20 <markbirbeck> But if we are moving towards not insisting, then it shouldn't go in.
12:42:44 <nick> Steven: I wish I understood what the problem is
12:43:20 <nick> John: ok, they are two different elements
12:44:09 <markbirbeck> My feeling is that we *should* insist on label, but at a semantic level. I don't know how to do that yet, but what I mean is that <label for="x" /> is a legitimate way to say that a control has a label. I.e., we shouldn't insist that the label be a *child* element, just because we want there to be a label present.
12:45:29 <nick> Roland: The modularization scheme isn't tied to schema, DTD, schematron,...
12:46:44 <nick> Steven: For example an 'a' doesn't allows an 'a' as a descendant this couldn't be expressed in XMLSchema but it can be SVG Shema
12:47:01 <nick> John: I just want to point out this weakness
12:48:58 <nick> John: If someone want to use XForms together with their custom IP control that doesn't requires labels
12:49:41 <nick> Raman: It are just the rules
12:50:02 <Steven> s/are/is/
12:50:40 <nick> Roland: If you don't allow it, will you require MarkB to create a control like input but isn't an input control
12:50:51 <nick> John: ...
12:51:19 <nick> Raman: It isn't that the labels wouldn't be required on the other input controls
12:51:36 <nick> John: Next item container module
12:52:15 <nick> John: there would be a Group Moudule,  switch module and repeat module
12:52:25 <Steven> s/Moud/Mod/
12:52:47 <nick> John: The repeat module will need an implicit instance for keeping the repeat index
12:53:12 <nick> John: What about the repeat attributes a separate module?
12:53:21 <nick> Uli: A separate module
12:53:54 <nick> John: What about the repeat-nodeset attribute?
12:54:09 <nick> John: Next we have the message module
12:54:20 <nick> John: Are those 4 modules in one spec?
12:55:04 <nick> Roland: I would like to separate the action from the other ones
12:56:20 <nick> John: Do these 4 things belong together in one spec
12:56:42 <nick> Roland: label belongs in the same category as message, help, hint and alert
12:58:15 <nick> Roland: help, hint and label could be put on all elements not only on form controls (alert is tight to forms)
12:58:28 <nick> Uli: They just show a special message
12:59:21 <nick> Roland: You can also see help, hint and labels as being triggered by a gesture 
12:59:44 <nick> Roland: label is triggered by the render gesture
13:00:12 <nick> Roland: it is a short desc, longer desc and even a longer desc
13:01:28 <nick> Roland: alert is only on a form field
13:02:14 <nick> John: So how many modules?
13:02:47 <nick> Roland: I can label, help and hint are useful in XHTML on elements
13:03:11 <nick> Roland: We never had the need for alert of message 
13:03:24 <nick> Uli: They are all messages
13:03:46 <nick> Roland: you can style them to be always visible 
13:04:42 <nick> Uli: We have text in the spec that says that help, hint and alert are messages
13:06:37 <nick> Roland: The whole page could be a message 
13:07:21 <nick> Roland: Uli you believe that I'm not allowed to style an hint so that it is always visible
13:07:29 <nick> Uli: yes your allowed to do that
13:08:07 <nick> Roland: Explains how label, hint, help can be used on all XHTML elements
13:08:19 <nick> Roland: But can't find a need for allert
13:08:43 <nick> Roland: Therefore I think it should be in another module
13:09:01 <nick> Roland: ... together with message
13:09:39 <nick> Uli: We can have one module for all, or a module for each, but not a union of some
13:10:58 <nick> John: label is separate already, hint and help together, alert and message
13:11:53 <nick> John: Would the driver add data binding to those elements
13:11:57 <nick> Raman: Yes
13:12:19 <nick> nick has joined #forms
13:12:50 <Zakim> -John_Boyer
13:12:51 <Zakim> -Cannes
13:46:32 <Zakim> +John_Boyer
13:46:53 <Steven> zakim, code?
13:46:53 <Zakim> the conference code is 36767 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), Steven
13:47:00 <Steven> welost raman
13:47:05 <Steven> we lost
13:47:48 <Zakim> +Cannes
13:51:37 <unl> unl has joined #forms
13:56:26 <nick> TOPIC: Future meetings
13:56:43 <nick> Nick: 3 or 4 is the same for my company
13:57:03 <nick> Steven: 3 days are fine for me and a virtual
13:57:57 <nick> Nick: Erik is also located in Palo Alto so he'll be probably there
13:58:25 <nick> John: Will we leave Feb. for what it is, and discuss June
13:58:32 <nick> Charlie: I like 3 days
13:58:49 <nick> Steven: 3 days is better for me too
13:59:05 <nick> John: Ok then we go for three days and virtual
13:59:45 <nick> Nick: If we to it on Wednesday then we have the 1.5 hour call 
14:00:15 <nick> John: Ok then we do on Wednesday and Thursday a virtual day of 4 hours
14:01:08 <nick> John: 4th and 5th Feb are the virtual days
14:01:23 <Roland_> Roland_ has joined #forms
14:01:40 <unl> unl has left #forms
14:01:47 <unl> unl has joined #forms
14:01:48 <unl> unl has left #forms
14:02:25 <nick> John: If we do 4 hours after the teleconf time
14:02:25 <unl> unl has joined #forms
14:02:59 <nick> Nick: Then we need to eat before 5pm or after 9 pm
14:03:23 <nick> John: What about one day on the 5th?
14:04:09 <nick> John: On Wednesday the normal call of 1.5h and a virtual day (like last week) on Thursday
14:04:45 <nick> John: We will do the same thing for the UK
14:04:50 <nick> Steven: OK
14:05:09 <nick> John: That will be June 4th on Thursday
14:05:27 <nick> ... we will have a virtual day
14:06:25 <unl_> unl_ has joined #forms
14:06:46 <nick> http://www.w3.org/MarkUp/Forms/wiki/FaceToFace
14:06:59 <nick> John: Two virtual days Oct. 28-29, 2009 9am-3pm eastern with 1 hour break at 12pm eastern 
14:07:19 <nick> John: Technical Plenary, 2-6 November 2009 or 16-20 November 2009
14:08:42 <nick> Steven: So since we are reducing the number of to two can't we do Tu-Thu
14:10:01 <nick> Nick: If we change it I'll have to travel on Sat. and we we will return on Sat
14:10:40 <nick> Steven: That's right, maybe we will stay with Mo-Wed
14:15:52 <nick> 2009
14:15:54 <nick> February:
14:15:54 <nick>     * Virtual day on Feb. 5 9am-3pm eastern with 1 hour break at 12pm eastern
14:15:54 <nick>     *
14:15:54 <nick>       PLUS 9-11 February, San Jose, USA Raman (Google) Hosts 
14:15:54 <nick> June:
14:15:55 <nick>     * Virtual day on June 4 9am-3pm eastern with 1 hour break at 12pm eastern
14:15:57 <nick>     *
14:15:59 <nick>       PLUS 8-10 June, London, UK Mark and IBM Host ? 
14:16:01 <nick> Oct/Nov:
14:16:03 <nick>     * Two virtual days Oct. 28-29 9am-3pm eastern with 1 hour break at 12pm eastern
14:16:05 <nick>     * PLUS Technical Plenary, 2-6 November (or 16-20 November), San Francisco Bay Area, California, USA (in conjunction with AC 2009) 
14:16:17 <nick> John: Who is going to do all this work
14:17:43 <nick> Nick: Isn't it is rewriting it as modules as much work as writing the XForms 1.0spec
14:17:52 <nick> Raman: I don't think so
14:18:01 <nick> Nick: You need to redesign a lot
14:18:11 <nick> Charlie Aggrees
14:21:02 <nick> Uli:   I need some more info for Submission  
14:21:29 <nick> John: Can you lead this on the next telecon
14:21:36 <nick> Uli: Yes
14:21:50 <Steven> s/Agg/Ag/
14:22:22 <nick> ACTION: Uli to prepare discussion about Submission on the teleconf of 29th of Oct
14:22:22 <trackbot> Sorry, couldn't find user - Uli
14:24:57 <unl> unl has joined #forms
14:27:03 <nick> (Going over the modules)
14:37:44 <unl_> unl_ has joined #forms
14:38:10 <unl_> unl_ has joined #forms
14:42:21 <nick> John: Form Controls contains custom controls and ui refreshings, ui binding attributes, ...
14:42:52 <nick> Charlie: I don't think we have to sign those up, there are people not here
14:45:56 <unl> unl has joined #forms
14:50:49 <nick> TOPIC: Name of the stream line spec
14:51:16 <nick> Raman: Call it Forms-A and not WebForms-A
14:51:28 <unl_> unl_ has joined #forms
14:51:30 <nick> Charlie: We are the Forms group
14:52:23 <nick> John: Forms-A
14:53:22 <nick> John: Good
14:53:42 <nick> Charlie: Can you update the draft, John?
14:53:55 <nick> John: I'll do
14:57:36 <Zakim> -John_Boyer
14:57:37 <Zakim> -wellsk
14:57:37 <Zakim> HTML_Forms()3:00AM has ended
14:57:38 <Zakim> Attendees were wellsk, John_Boyer, Cannes
14:58:28 <Steven> rrsagent, make minutes
14:58:28 <RRSAgent> I have made the request to generate http://www.w3.org/2008/10/21-forms-minutes.html Steven
14:59:36 <Charlie> Charlie has left #forms
15:01:05 <Roland_> Roland_ has left #forms
15:20:03 <nick> nick has joined #forms
15:38:05 <Roger> Roger has left #forms
16:13:08 <Zakim> Zakim has left #forms