Re: Draft minutes for 2008-01-16

Hi Leigh,

Is the date just a place-holder? :)

This part:

  Mark Birbeck: It has an id. Those are funny formulations we've implemented.
  Instances (except the first submission and instance rule) are
identified by id.
  So there's not any reason for submission to be tied to an id.

was actually:

  So there's not any reason for submission or instance to be tied to a model.

Regards,

Mark

On 16/01/2008, Leigh L. Klotz, Jr. <Leigh.Klotz@xerox.com> wrote:
> Please respond with corrections.
> Please start new threads for discussion.
>
>
>
>
> W3C Forms teleconference January 1, 2008
> * Present
> Charlie Wiecha, IBM
>  John Boyer, IBM (chair)
>  Leigh Klotz, Xerox (minutes)
>  Mark Birbeck, x-port.net
>  Steven Pemberton, CWI/W3C
>  Uli Lissé, Dreamlabs
>  Keith Wells, IBM
>  Roger Pérez, SATEC
>  Rafael Benito, SATEC
>
> * Agenda
> http://lists.w3.org/Archives/Public/public-forms/2008Jan/0017.html
>
> Previous Minutes
> XForms 1.1 Default Style for Form Controls
> Next FtF
> Charter Update
> Continue triage of future features
> Multiple Separate Constraints
> IRC Log
> Meeting Ends
> * Previous minutes
>
>
>
> http://lists.w3.org/Archives/Public/public-forms/2008Jan/0014.html
> IRC supplement:
> http://www.w3.org/2008/01/09-forms-minutes.html
>
>
> * XForms 1.1 Default Style for Form Controls
> http://lists.w3.org/Archives/Public/public-forms/2007Nov/0072.html
>
> Leigh Klotz: The #ui-processing section talks about inline layout and block
> layout and CSS, but appendix G.3 is now at odds with that and ought to be
> updated. *:disabled with visibility hidden isn't the way we do it. It shows
> both one we think you should do and what you might do.
>  John Boyer: So we should make it into two examples?
>  Leigh Klotz: Or get rid of it.
>  John Boyer: So we need someone to own it.
>  Leigh Klotz: I can collect the normative issues but someone else had to do
> the others. There are many holes in the way CSS and XForms are deployed
> together and so there are many fills for those holes.
>  John Boyer: So we need a re-write of this example but it's using things
> that aren't working everywhere.
>  Leigh Klotz: So we should collect together then ones that work.
>  John Boyer: Does CSS3 allow you to define your own pseudo-elements?
>  Steven Pemberton: It doesn't, but it ought to. We've said so in the past.
>  John Boyer: The response was?
>  Steven Pemberton: Put it in your own specification. It's not officially
> allowed but they said to do it.
>  John Boyer: So someone else creating a CSS3 might not do that.
>  Leigh Klotz: But someone implementing CSS3 and XForms would, as PicoForms
> had done.
>  John Boyer: Leigh you indicated you would collect together the things that
> work?
>  Leigh Klotz: The ones implied by the normative text.
>  Steven Pemberton: Then we can put in the list of special class names for
> when CSS2 or CSS3 isn't working. In Spain? Mark?
>  Mark Birbeck: I think that was in your house. Or Cannes. One of the action
> items was that I was to create some pages to comment on them. I have those
> pages but we've never discussed them.
> http://www.formsplayer.com/node/384
>  Leigh Klotz: I'm happy to do this but I don't want do neverending examples,
> but maybe just the form control layout as a full page.
>  Steven Pemberton: Here's a suggestion. Mark Seaborne is back soon. He's
> good at making XForms look really nice.
>  Leigh Klotz: I'll take a stab at form layout one and Mark or someone else
> can fix it later.
>
> Action 2008-01-1.1: Leigh Klotz to split appendix G.3 examples into two
> parts: a CSS file of stuff implied by the rest of the spec, using both CSS3
> and the substitute class names from
> http://www.formsplayer.com/node/384; an example of form
> layout for elaboration later by others.
> * Next FtF Feb. 1 virtual day plus Feb. 4-6 in North Carolina; Details page
> needed. http://www.w3.org/MarkUp/Forms/wiki/FtF_2008_02/
>
> Steven Pemberton: Registration is now working; please go register.
> * Charter Update
> http://www.w3.org/MarkUp/Forms/#deliverables
>
> John Boyer: I reset the date to February 2008 for the first public draft
> because I expect it to be an outcome of the F2F. We need to have some
> sections already picked and elaborate them during the F2F. That's my sales
> pitch. I did a lot of work in the Wiki recently:
> http://www.w3.org/MarkUp/Forms/wiki/XForms_Future_Features
> I tried to divide it up into two versions and assign priorities for 1.2 and
> 2.0.
> * Continue triage of future features
>
>
>
> Wiki
> http://www.w3.org/MarkUp/Forms/wiki/XForms_Future_Features
> John
> http://lists.w3.org/Archives/Public/public-forms/2007Dec/0006.html
> Nick
> http://lists.w3.org/Archives/Public/public-forms/2007Dec/0008.html
>
>
>
> John Boyer: The first issue is simplification. Are we comfortable with not
> having a model element?
>  Mark Birbeck: The default is that they're free-floating and a model element
> then sets the evaluation context for bind and submission.
>  John Boyer: What if you put an instance inside a repeat, or a group?
>  Mark Birbeck: It has an id. Those are funny formulations we've implemented.
> Instances (except the first submission and instance rule) are identified by
> id. So there's not any reason for submission to be tied to an id.
>  John Boyer: So when the referrer and the referred are both inside a repeat
> we have the rule.
>  Mark Birbeck: Ah so do you repeat the instance? We may have to restrict
> some things. Just setting an evaluation context, action handlers, etc. all
> inside a model and you don't need to use an instance() function. There's the
> ability to re-use stuff so you could hand a model. It would have all
> handlers, etc. and would log you into GData.
>  Charlie Wiecha: The converse is moving scratchpad instance closer to where
> it's used.
>  John Boyer: So does it take its context from the data or the reference?
>  Charlie Wiecha: No proposal yet.
>  Mark Birbeck: We allowed model not to be restricted to the head; we have
> blocks of code instantiated dynamically but we need a model. Say you are
> doing a select using a "Google Suggests" AJAX approach. Those values have no
> relevance to the rest of the form; it's a scratch instance, as Charlie said;
> it has a little submission as well. That can fit very close to the control
> that it's.
>  John Boyer: There's refactoring into modules, etc. as XForms 2.0.
>  Mark Birbeck: The form element, for example.
>  Charlie Wiecha: The example Mark gave doesn't quite get into that turf.
> Just a free-floating instance is fine without modularization. We need to
> divide 1.2/2.0 more carefully but I think it's ok.
>  John Boyer: So free-floating instance by id only?
>  Mark Birbeck: Hmmm...the first instance rule? Not mixing 1.2/2.0
> features...how do you go from an HTML form to an XForm...making model
> optional lets us interpret an HTML form as if it were an XForm, so we don't
> need complete flexibility. If letting the instance free-float is too far,
> ok.
>  Charlie Wiecha: If it doesn't fit the on-ramp.
>  John Boyer: If we had a free-floating instance then the one without the ID
> would be the default. So Steven said it would be the first instance in the
> form tag; if you specify no instances then you get the default.
>  Charlie Wiecha: Then you pull the controls inside the model rather than
> having a model-free.
>  John Boyer: It's like an implied group.
>  Charlie Wiecha: That's very nice.
>  Mark Birbeck: Model is still a key term in procedural aspects (rebuild,
> etc). So it's a processing concept rather than a markup concept. Then form
> controls can be inside model.
>  Charlie Wiecha: The events are dispatched to form instead of some anonymous
> node inside the form.
>  Mark Birbeck: So xf:action under form will still give you rebuild. So form
> represents all those things; you'll get the submission events as well.
>  John Boyer: model-construct-done and xforms-ready. We might come up with a
> simpler way to express defaults and initialization.
>  Charlie Wiecha: It might be nice.
>  Mark Birbeck: And if an author suddenly needs three submissions in a form,
> fine.
>
> John Boyer: What if you want to use an instance for a particular reason, but
> you don't actually want that instance to overload the default instance
> implied by the UI? For a web service?
>  Mark Birbeck: You then create a model, instance, submissions, for the web
> service.
>  John Boyer: Then you need cross-model communication?
>  Leigh Klotz: Doesn't Charlie do that with XAC?
>  Charlie Wiecha: 2.0. Use a listener.
>  Mark Birbeck: I thought we could do cross-model setvalue?
>  John Boyer: No, only one model.
>  Mark Birbeck: We have a getGlobalInstance function. You have to be careful
> in a bind as it doesn't create a dependency. It moves data a to location b.
>  John Boyer: Or have it called only in an action.
>  Leigh Klotz: How about a submission target that's an instance in another
> model.
>  Mark Birbeck: But you still need a function. Ah you mean the instance
> attribute?
>  John Boyer: Right now it says it's only in the same model.
>  Charlie Wiecha: How about nesting them?
>  John Boyer: I added nested models to the Wiki. Instances could be made
> visible to containing models. So the model inside a form could have internal
> access to its first instance by default but operate over the model of
> instances in its ancestor container models.
> http://www.w3.org/MarkUp/Forms/wiki/Nested_models_for_convenient_grouping_and_composition
>  Charlie Wiecha: That seems more bounded.
>  Mark Birbeck: So all nested model elements add to the outermost model. The
> only bit you gain by nesting them is the evaluation context.
>  John Boyer: If you have a model that is operating in isolation and compose
> something with it, and then that changes the default instance, it breaks as
> soon as you compose it. If calculates in it rely on the default instance in
> that model and then you put it inside some other model, if we claim the
> nesting amalgamates them together, then the submodel gains the first
> containing model's default instance.
>  Charlie Wiecha: No, that's not what we're saying.
>  Mark Birbeck: If we have a reference inside a model with a /, that refers
> to the first instance in that model. If I put that inside another model,
> it's still the same. But for rebuild and recalculate, when the submission
> has finished, you'll need to a rebuild on all the models all the way up the
> chain because you have one model. The nesting is for scoping only, like a
> block. We'd have cross-model problems if we don't do rebuild on the
> contained models.
>  John Boyer: There's some optimization issues there for very large ones.
>  Mark Birbeck: If a nested model is allowed to refer to any models in the
> hierarchy above it, then it's the same as siblings.
>  John Boyer: So access is automatic.
>  Mark Birbeck: But you have to rebuild everything.
>  John Boyer: Over time it becomes an optimization issue.
>  Mark Birbeck: So we should look further into optimization as we said in
> 1.2.
>  John Boyer: If we limit cross-model access to a containment scenario, it
> might be easier to deal with other time because you don't have arbitrary
> connections.
>  Charlie Wiecha: How about the parent to the submodel as well? You need
> that.
>  John Boyer: Yes, more in the way Mark has described, where the containment
> goes both ways. The default reference is in teh descendant model.
>  Leigh Klotz: So the namespace is flat.
>  John Boyer: In terms of ids.
>  Mark Birbeck: We are restricted by XML itself. Maybe use name?
>  Leigh Klotz: Or use reference instead of inclusion and the ids would be
> other documents, as can be done with XML Events.
>  John Boyer: We use sid, scope ID, unique in the containing element.
>  Mark Birbeck: In experiments I've done with creating models to be re-used
> the issue is to try not to refer to things inside the model, which sounds
> kind of obvious. Using events as the main mechanism is more useful.
>
> John Boyer: Why do you need to be able to go both ways for web services?
>  Charlie Wiecha: We need setvalues to go...
>  John Boyer: So that's done in the child model; it gets data values from the
> ancestor, pulls them in, and then pushes the values out to its ancestors.
>  Charlie Wiecha: I thought the ancestor would set up the payload submission.
>  John Boyer: So it would attempt to launch a submission but push its data
> into the web service.
>  Leigh Klotz: How about a ref or instance on xf:send, so you can define a
> point where you pass the parameters down, and then don't do any bind access
> at any other time, preventing problems with rebuilds.
>  Charlie Wiecha: We started off with default instance question.
>
> John Boyer: Can we focus on a straw proposal and see what we can do for 1.2?
>  Charlie Wiecha: I'd like to get started on it.
>  Mark Birbeck: Maybe we can start with the form element.
>  John Boyer: That which implies a model plus submission.
>  Mark Birbeck: Plus default instance, and then working on the problems that
> happen when you introduce an explicit version of what you had implicitly.
>  Charlie Wiecha: We could spec the form tag in XBL.
>  John Boyer: That's neat; as we're in the Interactivity domain, move from
> text+schema to text+xbl. So who gets the action?
>  Charlie Wiecha: I can do part of it.
>  Mark Birbeck: That's a model I described in my paper
> http://www.w3.org/2004/04/webapps-cdf-ws/papers/webapps-workshop-standards-based-vm.pdf
>  Mark Birbeck: I think it's testable as well as convenient. So I would like
> to work with Charlie on this.
>
> Charlie Wiecha: In Cannes we had this admonition to use more formal methods.
> Is XBL formal?
>  Mark Birbeck: I've defined xf:instance/@src in terms of xf:instance without
> a src but with an event handler on document load, etc. It's more the kind of
> composite nature. It's sort of in XBL as that's the best we have for
> composite objects, but we might have something better.
>  Charlie Wiecha: XBL is element-driven, but if you extended it to cover that
> level of granularity you might cover that case. I've discussed a way of
> doing XBL with XHTML with Steven. You can use the HTML root element and you
> only need a couple of extra things.
>
> Action 2008-01-1.2: Charlie Wiecha and Mark Birbeck to work on straw
> proposal for making model optional, allowing submission elements without
> model elements, and allowing instance elements without model element.
> Results to
> http://www.w3.org/MarkUp/Forms/wiki/XForms_Future_Features
> * Multiple Separate Constraints
> http://www.w3.org/MarkUp/Forms/wiki/Multiple_separate_constraints
>
> John Boyer: One of the obvious ones is constraint.
>  Leigh Klotz: The analysis I did a while back on this showed ways to combine
> them. There's AND and OR.
>  John Boyer: It seems rather obvious that and is the way to combine them.
>  Leigh Klotz: We might want to have a constraint-valid attribute and a
> constraint-invalid attribute and then to be valid you have to have either at
> least one constraint-valid=true or no constraint-invalid=true.
>  John Boyer: I see. But what if you have both?
>  Leigh Klotz: I guess the invalid wins.
>  John Boyer: Then that's what we have now.
>  Leigh Klotz: But it's tri-state like CSS :enabled :disabled, which have
> their own boolean values true/false, and some cases simply give you no
> information.
>  John Boyer: We need to ask if this is valuable for 1.2 and makes authoring
> easier. The same is true for other issues such as model-based switch. We can
> discuss more next week.
> * IRC Log http://www.w3.org/2008/01/16-forms-minutes.html
> * Meeting Ends
>


-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@formsPlayer.com | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.

Received on Wednesday, 16 January 2008 21:12:03 UTC