W3C Forms WG Virtual Face to Face Day, 11 June 2009

11 Jun 2009


See also: IRC log


kenneth, wiecha, John_Boyer, ebruchez, nick, unl, Steven, Leigh_Klotz
Charlie, wiecha, nick, Steven, klotz




<John_Boyer> Scribe: Charlie

<Steven> CONF1

<wiecha> scribe: wiecha

Disposition of Comments on XForms 1.1 CR

Steven: is the first issue on the list an actual issue?
... before the date of CR draft

John: thinking we could skip that one since it was also answered

Steven: what's the answer?

John: in December...
... we've been pretty good about answering everything in this list...


John: issue disguised as question

<John_Boyer> http://lists.w3.org/Archives/Public/www-forms-editor/2007Dec/0000.html

John: nature of events allows for the utility of iteration in cases that were questioned
... even more so, we're trying to be modular
... and not introduce exceptions where not needed
... disposition is "answered"


rejected since the example cited is actually correct

Nick (author): I'm ok with that result


John: accepted and fixed in spec



scribe: but not replied
... changed in spec


<John_Boyer> http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#submit-submission-element


modified and accepted


duplicate, replied directly


accepted and updated in spec


modified and fixed

<unl> Steven: s/Ficed/Fixed/

<Steven> I had already ficed that one ;-)


accepted and changed


editorial, rejected as cases are different

originator accepts


accepted and changed

author accepts



<John_Boyer> scribe: nick

Fixed this and send direct response


accepted and fixed it replied on the other list

is editorial


accept & fix


<John_Boyer> The person who raised this issue with me verbally caused me to write this email, but it is clear that their point is invalid since their method creates non well-formed XML, so I withdraw the comment asking for a clarification

<Steven> This is about issue http://lists.w3.org/Archives/Public/www-forms-editor/2009Jan/0001.html

<Steven> s/iisues/issue


accept and fixed, clarification



Steven: We should ask Vlad to respond positive on it

<John_Boyer> http://www.w3.org/MarkUp/Forms/2009/xforms11-PR-DoC.html


editorial issues accepted


editorial, fixed, replied to


<ebruchez> good morning, what's the call-in information?

<ebruchez> thanks Nick/Zakim ;)

editorial, modify and accept, replied to


editorial, fixed, replied


the answer is already in the spec, no change necessary, replied

<Steven> http://lists.w3.org/Archives/Public/www-forms-editor/2007Dec/0001.html

<Steven> http://lists.w3.org/Archives/Public/www-forms-editor/2007Dec/0002

<Steven> Nick,. are you happy with that reply?

I'm happy with the response http://lists.w3.org/Archives/Public/www-forms-editor/2007Dec/0002 for http://lists.w3.org/Archives/Public/www-forms-editor/2007Dec/0001.html

<Steven> I am happy with the reply at http://lists.w3.org/Archives/Public/www-forms-editor/2008Apr/0001

<Steven> http://lists.w3.org/Archives/Public/www-forms-editor/2008Jan/0001.html

For me '11.2 The xforms-submit Event - concurrent submissions' is an accept not a Modify and Accept, we just reworded what he was proposing

John: agree that '11.2 The xforms-submit Event - concurrent submissions' is just an Accept

looks good

John: yes

Steven: Do we resolve to add a link to the DC in the current draft?

John: OK

<John_Boyer> http://www.w3.org/MarkUp/Forms/wiki/vFtF_2009_06_11

Steven: We can just change the status, the original resolution was about the content not the status

Agenda and XForms 1.2

John: I think these http://www.w3.org/MarkUp/Forms/wiki/vFtF_2009_06_11 items are the ones which are most urgent and we prob. can get the most velocity on those
... Most of the items are just small diffs, there are only a few of multiple pages
... People can produce the spec ready text in the next week, and we can talk about it next week
... Is this a decent plan?

group: aggrees

John: Next on the agenda are some items that need some more discussion... the Focus on Submission Improvements are probably not going to be completed in 1 hour
... The focus on UI improvements needs to be probably going to be discussed on the list first because we are an hour late


<John_Boyer> scribe: wiecha

<John_Boyer> http://www.w3.org/MarkUp/Forms/wiki/vFtF_2009_06_11

Create Team Plan for PFWD of XForms 1.2

PicoForms and Orbeon have lists of features already implemented and also high priority items

linked above

many are already on future-features list

and some have been implemented as well by others in their own ways

implying there's a good place to start wrt standardization

John: tried to go through longer list on this link:

<John_Boyer> http://www.w3.org/MarkUp/Forms/wiki/Future_Goals

John: and to delete things that weren't as important, urgent, too big etc
... so have a list of things that are quickly doable

e.g. case() function

scribe: vs. something like dialogs will require more technical work...not so low-hanging fruit
... will likely be other things going into 1.2 but wanted to have a list to start quickly on
... for the june f2f (e2e) days
... pls suggest others if you have them
... let's go through sequentially and set some action items for first draft of spec-like text
... first is context everywhere, context on bind elements
... top of the list due to thematic clustering not priority -- not a prioritized list
... first two points are about xpath
... issue with this item is there's already an action item, did work in binding attributes spec
... talking about creating a delta spec as first working draft of xforms 1.2
... so some of the work is to take previous text and rework into paragraphs for delta spec

<scribe> ACTION: John_Boyer to write up first spec text for context everywhere, context on bind elements [recorded in http://www.w3.org/2009/06/11-forms-minutes.html#action01]

<trackbot> Sorry, couldn't find user - John_Boyer

John: next topic is custom xpath functions, also from host language, e.g. js
... understand there are implementers doing custom xpath functions in various ways

e.g. ubiquity xforms

scribe: also in picoforms? (yes)
... not yet in orbeon

Erik: Kenneth, do you have examples of syntax to do this?

Kenneth: yes, we support several scripting languages in addition to JS
... is this from API or markup level? guessing from markup
... ok, I can send something to the list

<John_Boyer> <script src="format.js" type="text/javascript">/**/</script>

<John_Boyer> function currency(value, digits) {

<John_Boyer> ...}

<John_Boyer> <xforms:output class="regular" value="javascript:currency(number())">

<John_Boyer> xmlns:javascript="http://www.w3.org/2002/xforms#inline"

Nick: do you require an XML declaration?

John: in the case of JS we just defined a namespace below xforms with #inline...could talk about what that looks like...
... when looking for functions in that namespace, there's an implementation defined way to get to those inline functions

there's no definition of how to resolve, just how to reference

Nick: in some JS implementations need a declaration of arg list and types etc

John: yup, makes sense
... one of the goals of the stds effort is to get things to interoperate
... if each impl followed its own methods for resolving references, the markup itself would still interoperate

Erik: thought the idea was to be able to define xpath functions using xforms itself...a combination of actions

John: we should look at both
... am most interested in composing actions

Erik: clearly use cases for both
... seems like the work is fairly different for the two cases

John: functions should not have side effects
... if we run a set of actions that cause events which then take other "actions" can be problematic
... e.g. during recalculate start get insert and delete events which cause setvalue actions etc etc
... no way to determine order if calculations have side effects with dependencies that are not visibile
... same problem for custom JS which calls DOM API

Charlie: forces complete rebuild

Erik: good point but inevitable with general extensibiility through xpath
... not fixable other than telling function implementors to be careful
... safe vs. unsafe actions -- impossible to avoid the problem entirely
... some use cases are ok, ... (lists couple of examples, missed details)

Nick: what are the use cases of functions that change the DOM? maybe if we have fns that don't change anything vs those that do we can avoid the problem

John: yes, by limiting the parameter stack...

<nick> correction have custom actions, than can change the DOM

Erik: or for example not show updates until after query completes to limit scope of changes
... harder to handle in procedural languages than, for example, in xquery update
... can contain potential scope of changes and do analysis more readily

John: yes, but back to Nick's point if we create custom "actions" do we need xpath functions that also perform mutations?
... reading xpath 1.0 there's no support for fns that do updates

Nick: neither in xpath 2.0
... and even in xquery update can only update a given subtree once during any given query

Erik: proposal would be functions w/o side effects affecting the DOM and secondly reusable actions which can be easily called
... we currently simulate reusable actions by dispatching events to approximate procedure calls

John: when talking about custom xpath fns in terms of xforms actions we talked about limiting scope of what they could mutate to just local variables
... a fn implementation would have local model, for local vars, produce return result...only mutate within this local scope
... might contain the complexity
... start with a somewhat limited functional scope like this and see if more is needed later
... is this a topic that anybody wants to drive? with first draft of spec-like text for 1.2???

Erik: not sure if we should skip it but someone who has already implemented it would be great
... don't know if anyone has yet done it...
... might be good to have somebody experiment first

John: not sure if there's much diff between javascript invocation with limited scope and xforms actions that operate over local model...
... typically have implementors who have multiple designs different from the "standard" one which usually happens during CR phase when they migrate to the spec mechanism

Charlie: thought Erik was proposing doing that first

John: not xforms actions version, no

Erik: there are use cases that are much simpler...not necessarily with nested models etc
... e.g. xpath expression reuse
... over multiple lines, particularly in xpath 2.0 with conditions, for etc
... happens in xpath 1.0 too
... just having a short-cut form for longer xpath expressions would be useful
... could be a simple templating mechanism

John: biggest problem with that kind of "function" (which could run an xpath that referenced instance data in the model rather than its parameters) is also a problem for recalculate engine
... unless input parms are the only things the reusable xpath can operate on then have problem seeing dependencies of a calculate containing that fn call

Erik: yes, have that problem in general
... as per previous discussion have to run the xpath expressions any way to determine dependencies

John: the problem is when we calculate nodes an expression is dependent on, with a fn call the only nodes we see are those that are used to form parms, return result

Kenneth: usual for impl to look at the actual body
... e.g. in JS, more complex but not always just the external signature

Erik: not sure about the JS case but for xpath should be doable
... looking at the expression tree -- supports both static and dynamic analysis
... can contain fn calls to sub-xpath expressions as well

John: need to see nested xpath expressions up at the dependency graph level

Erik: you'd build a single expression tree in xpath
... so can optimize over entire tree
... so doesn't matter if expression is nested in custom fns or inlined

John: more of macro substitution

Erik: same effect
... but smarter than macros
... xslt already has fns, xquery too
... except for scoping behavior is the same as in-lined code

John: even in case of running actions, those are expressed in terms of xpath-based attributes (ref, origin, etc)
... we could still possibly end up with a way to analyze a composite action-based fn to determine its dependencies

Erik: yes, by building a unified tree of xpath and xforms actions

<nick> What about :

<nick> <xf:function name="my:greatFunc" result="xs:integer" expression="$param1 * $param1 div 2 + avg($param3/price)">

<nick> <xf:param name="param1" as="number()"/>

<nick> <xf:param name="param2"as="number()"/>

<nick> <xf:param name="param2"as="node()"/>

<nick> </xf:function>

<nick> or something like that

John: coming back to question of anybody want to take this one?

Erik: unless we have a proposal, maybe look at other stuff first
... but this is interesting
... there is a set of missing xpath functions needed in xforms...not "custom" but more pre-defined that people need
... extensions to xforms fn library
... number, time, date formatting for example
... we took xslt fns and exposed into our own namespace so we can use in xforms...are lots more
... good candidates for xforms 1.2 update

John: if there are some docs we could look at this would be helpful
... good transition to bottom point, mechanism to adopt xpath 2.0 optionally
... even if on model we say i'm xforms 1.2 and xpath is 2.0
... will pick up some of the fns just described

Erik: better to just implement xpath 2.0, yes
... rather than adding lots of stuff by copy to xforms

Nick: some fns in xforms have same names as xpath 2.0 but have slightly different results

<ebruchez> For reference, the XProc spec's take on XPath 1/2 http://www.w3.org/TR/xproc/#xpath-context

John: to do in "dot" release would have to declare at model level which version of xpath you're using
... so backlevel forms will be compatible

Erik: XProc has xpath-version to control this
... with exception if content asks for xpath 2.0 and it's not available

John: this is a good pattern to look at, continues the path toward xpath 2.0
... makes it optionally available, then maybe in xforms 2.0 it's the only version
... becomes just available in dot release

Nick: in xproc is it at top-level only or can switch within the doc?

Erik: yes, seems possible in narrower scopes --
... it's different in xproc since the steps are fairly isolated
... not sure if this still makes sense in xforms

John: don't do this in model with @version
... @version on default model governs all models on the page...coarse grained and this is ok

Nick: that's ok but in xslt can do finer grained...stuff you're importing can be different

John: might be helpful to say on a model-by-model basis what engine is used

Nick: might be a bit confusing since at the UI layer can switch between models

John: right
... let's walk first

Erik: actions outside of model, and switch in UI, ... what's the default? could be come messy
... can also put xpath 2.0 impl in 1.0 mode...close but not exact. would allow not having two impls of xpath

<scribe> ACTION: nick to work up xpath 2.0 as optional for dot release of XForms [recorded in http://www.w3.org/2009/06/11-forms-minutes.html#action02]

<trackbot> Created ACTION-549 - Work up xpath 2.0 as optional for dot release of XForms [on Nick Van Den Bleeken - due 2009-06-18].

John: should also include discussion of xpath version attr

Nick: yes, will also look at list of fns that might conflict with xpath 2.0

John: would be very helpful to include in spec writeup

<ebruchez> back

<Steven> scribe: Steven

John: Alright

XML Events 2

<nick> John: In XHTML 2 XForms was adopted, is XML Events 2 is also in XHTML 2

<nick> Steven: Yes

<nick> Nick: I had a look at integrating XML Events 2 in XForms and we had a meeting about it at the previous Tech Plan

<nick> Steven: I think everything has been ironed out

<nick> John: We need a delta spec for using XML Events 2

<nick> Nick: For example dispatch is now dispatchEvent and targetid is now destid

<nick> ACTION: Steven to write spec ready text for adopting XML Events 2 in XForms 1.2 [recorded in http://www.w3.org/2009/06/11-forms-minutes.html#action03]

<trackbot> Created ACTION-550 - Write spec ready text for adopting XML Events 2 in XForms 1.2 [on Steven Pemberton - due 2009-06-18].

XML Events 2 has the same namespace

Node "create" action

<nick> Nick: Do you want an action to create a node, or is xpath function that creates a node sufficient, and use our insert action to insert the node

<nick> John: That sounds good then we can use the standard insert action and eventing

<nick> ACTION: Nick to write spec ready text for an xpath function that creates nodes (elements, attributes) [recorded in http://www.w3.org/2009/06/11-forms-minutes.html#action04]

<trackbot> Created ACTION-551 - Write spec ready text for an xpath function that creates nodes (elements, attributes) [on Nick Van Den Bleeken - due 2009-06-18].

Dispatch event with contextinfo

<nick> John: There is no way to set context info for the events you send

<nick> Steven: What context info you want

<nick> John: For example all the context info we specify for our xforms events

<nick> Erik: Orbeon has an extension to set the context information of events that are dispatched by dispatch

<nick> ... the use case is for context information for custom events

<ebruchez> <xforms:dispatch name="fb-prepare-span-grid" target="fr-form-model">

<ebruchez> <xxforms:context name="grid" select="$grid"/>

<ebruchez> </xforms:dispatch>

Looks like an instance

<John_Boyer> you could also use nodeset or value

<nick> <xforms:dispatch name="rename-control" target="my-model">

<nick> <xxforms:context name="my:control" select="my/control"/>

<nick> <xxforms:context name="my:control-name" select="'beverage-selection'"/></xforms:dispatch>

<nick> Keneth: Some context information is not data

<ebruchez> thx

<nick> ... example mouse information

<nick> John: You could use the property function to return that data

<nick> Nick: You could create a processor specific function

<klotz> wiecha, code?

<nick> Erik: There is also the use case to add some context info to an event that is already dispatched

<nick> Erik: In some cases you don't want to copy the event

<nick> John: Not a lot of xforms events have context info

<nick> Erik: In our implementation we have a lot more context info

<nick> John: Has XMLEvents 2 has support for adding context info

<nick> Steven: No

<nick> Steven: You could either add it or even better send a comment to the XML Events 2 WG

<nick> ...

<nick> John: We have to say something about the evaluation context for if and while

<nick> Steven: Isn't the context like an instance

<nick> Erik: You want more information about the entries in the context definitely in XPath 2.0 where you have sequences, dates, times, ....

<nick> John: What is the status of XML Events 2

<nick> Steven: You can always comment

<nick> Kenneth: Could everybody consume the context info not only XForms?

<nick> Charlie: That is what I want it to do, I want to access it from for example Javascript

<nick> Keneth: We have not all types in XForms for example a node from a host document

<nick> Charlie: I wasn't worried about dispatching existing events, I just want to dispatch custom events with context info and catch it in Javascript

<nick> John: I agree with erik there are 2 problems:

<nick> - How do we define the context info

<nick> - How do we access the information that needs to be put in the context info

<nick> ... but those are two separate actions that should be done

<nick> Erik: I still don't see what the problem is with issue 2

<nick> John: You can't always access all information that needs to set in the context information, for example the host document element where the dispatch is coming from, which is a DOMNode from the host document

<nick> Erik: The answer is an extra XPath function to access the host document

<nick> Kenneth: We just note this somewhere that we won't be able to dispatch all standard DOMEvents

<kenneth_> example of standard event using a host document node: mouseover

<kenneth_> The mouseover event occurs when the pointing device is moved onto an element. This event is valid for most elements.

<kenneth_> Bubbles: Yes

<kenneth_> Cancelable: Yes

<kenneth_> Context Info: screenX, screenY, clientX, clientY, altKey, ctrlKey, shiftKey, metaKey, relatedTarget indicates the EventTarget the pointing device is exiting.

<nick> John: Any volunteers to write this down?

<nick> http://www.orbeon.com/ops/doc/reference-xforms-extensions#dispatch-context

<nick> ACTION Erik to write spec ready text for passing context info on the dispatch action

<trackbot> Created ACTION-552 - Write spec ready text for passing context info on the dispatch action [on Erik Bruchez - due 2009-06-18].

Focus on External Model and Submodel Problem

<nick> John: Put them together because if they are done independently they just don't do enough

<John_Boyer> take 5

What message do you get Nick?

<unl> nick: try login ;-)

<ebruchez> FYI I will be on the call for another 1/2 hour only

<John_Boyer> scribe: klotz

John: External Model
... src attribute? sharing models across pages is the goal? Steven?

Steven: That was my major reason. Several forms with the same model. The model encapsulate the data and constraints.
... It's better to say "here's the model" than "here's the instance."

John: Consider two web pages, operating over the same XForms model.
... Constraints for complete data. Then we have to get from page 1 to page 2.
... Use a submission to do that;
... On submission from p1 to p2, you've only filled out some of the information, and you won't satisfy all the constraints for the whole model.
... So turn off validation entirely, or you need some way to subset constraints.
... This is how I concluded that we needed sub-model capability.
... So, "Here's a portion of the model."

<nick> XInclude supports this by using XPointer

Steven: I'm not sure yet. What's the interface between p1 and p2?

John: Both operating on the same model.

Steven: I wanted different things with the same data: one form for adding new people, another for changing password.

Leigh: I'm hearing states: states for submission transitions, states for admin-vs-regular user.

Charlie: I think there is more than one use case.

John: How to two different web pages use the same model?

Charlie: Update, View, Delete. Different pages, different roles, different access.
... Instance data shared only?

John: We already have source on instance.

Steven: A model can use bind to hide the structure of the instance.

John: The set of binds may vary. Or a model with just binding sites.
... But with constraint or required you can't use this mechanism because you need required mips for each subset of data.

Steven: If I say that dob<yod that doesn't change according to which form.

John: If you open the form that doesn't allow yob then the year data node may be empty.

Steven: How's that different from the situation now?

John: Right now we assume one model; a constraint on data and no edit for the data, then it's a broken form.

Steven: How's that different from the situation now?

John: Now we say the form is broken. If you want an external model...create a model with node a and node b with constraints and two forms, one editing a and one editing b.
... Common model has constraints, but you can edit only one node, so you fail if the node.

Steven: If I import the tax law readonly instance and constrain values you can't change the tax law; you have to change your value.

John: Your user can edit their value. A common model shared between two forms, one form edits subtree a and the other subtree b
... When you use form a you only want subtree a constraints active because you don't allow them to modify data in subtree b.

<John_Boyer> Form A.html

<John_Boyer> <model src="model.xml"/>

<John_Boyer> <xf:input bind="A"> ... </xf:input>

<John_Boyer> Form B.html

<John_Boyer> <model src="model.xml"/>

<John_Boyer> <xf:input bind="B">...</xf:input>

Erik: One page has A and model.xml, another page as B and model.xml.
... You want to navigate.

Steven: No, that's John's situation.

<John_Boyer> model.xml:

Steven: I have a complicated model with datatypes and want to put it in one place.

<John_Boyer> <model> <instance><data> <a/> <b/></data

Steven: Like a stylesheet.

<John_Boyer> model.xml:

<John_Boyer> <model>

John: Suppose I have a form A with a model and a form B with a model, and XForms input in each binds to the model

<John_Boyer> <instance>

John: If both bind to the model:

<John_Boyer> <data> <a/> <b/> </data>

<John_Boyer> </instance>

<John_Boyer> <bind id="A" nodeset="a" required="true()"/>

<John_Boyer> <bind id="B" nodeset="b" required="true()"/>

John: When in form a you want the user to enter value a; when in form b you want the user to enter a value for b.

<John_Boyer> </model>

<John_Boyer> Now try to add a submission?!?

Erik: Re-use is fine but sometimes you need parameters.
... You can put it in the request parameter.

<John_Boyer> How do you get page A to only respect the required MIP on node A?

Leigh: Use REST and it's a resource, not a file.

<John_Boyer> How do you get page B to only respect the required MIP on node B?

<model src="/get/me/page?john=a" />

<model src="/get/me/page?john=a" />

<model src="/get/me/page?john=b" />

John: So your model generated has a subset of binds.

<Steven> <model src="m.mdl"> <bind bind="b" required="false()" /> </model>

Leigh: Steven wants to write <model src="..."/> and you want to provide different models in different situations.
... You both win.

John: So this is a different idea for subsetting models.
... So Leigh is saying model subsetting is done by server-side code.

Leigh: I think it's orthogonal.

<ebruchez> it can be also done by parametrization of the model

Leigh: It doesn't override, does it?

Steven: It overrides it.

<ebruchez> the XForms loads the same model, sees the same markup

Leigh: That's a while different an of worms.

<ebruchez> but the model can parametrize itself, or be parametrized by the user of the model dispatching events to it, or setting instance values

John: You suggested assuming a rest process at the other end.

Leigh: We have no control over it.

John: That's not the solution to the problem, it's a problem.
... Web content can get published as a bucket of bits, so if you publish static content for re-use in multiple pages, you can't.

Leigh: You may need something more expressive in the model, but the example you gave doesn't motivate anything other than HTTP GET.

Kenneth: Isn't relevance enough?

John: The model still needs to know the page it was invoked from.

<kenneth_> page1:....

<kenneth_> <setvalue ev:observer="m1" ev:event="xforms-ready" ref="i">1</setvalue>

Kenneth: It can know that with a single line of code.

<kenneth_> page2:.....

<kenneth_> <setvalue ev:observer="m1" ev:event="xforms-ready" ref="i">2</setvalue>


John: Then you write your model to case the constraints with relevance rules.

Kenneth: I agree, but no matter what construct for expressive power we come up with we need something to make sure it's not evaluated for validation. It would do more or less the same thing.

John: This is good.
... So you're saying the sub-model is already there.

Kenneth: Not everything about sub-models.

John: But enough to solve the problem I posed.

Kenneth: It's not beautiful but possible; I'm doubtful that we can have a better way to express it.


<bind if="foo"><bind ...> <bind ...> <bind ...> </bind>


Kenneth: Nested bind.

John: src on bind helps.

<bind ref="/*[/foo=3]">

<bind if="/foo=3" />

<John_Boyer> nodeset

<bind nodeset="/a/b/c[/foo=3]" >

John: We can do it with predicates, model src, bind src, and model-construct-done cleverness.

Leigh: Now that we know how we're doing it, what is it that we're doing?

Charlie: There's a broader class of problems to attack.

John: Identifying the broader class and creating machinery.

<John_Boyer> takes more time

Leigh: Maybe we can do some simple syntax that turns into these tools that we've found and added.

Charlie: It's functional but doesn't capture the intent.


John: We don't have the pattern yet.

Charlie: We have one example.

John: We have ideas for more complex applications, so let people have this and creating more patterns.

Charlie: One use for external model is definition of service.
... Interfaces, operations, etc. As in Raleigh. Maybe even embed multiple copies of the same instance.
... A searching service with instance, binds. Model id a goes against one search site, model b another.
... Import as external references with their own complex internal IDs.
... Deal with them separately; it's a different use case than Steven's code consolidation and John's variant constraints.
... Does the use case make sense?

<Steven> Maybe we need to associate binds with instances rather than models

Steven: We are a little bit allergic to cross-model relationships. We like models to contains all the details of a form. A model collections binds and instances.

John: A model including models would be a sweet spot.
... The model could be as simple as

Steven: textual inclusion

John: You could create a model that has instance bind submission for a particular web service endpoint WSDL

Charlie: What if we refocused on the instance instead of the model?
... What if we wanted to construct something that looks like one with type info and it's what's currently called a model.

John: I don't understand "construct"

<John_Boyer> we only construct once

<xyz if="pred" /> --> <xyz ref="abc[pred]" /> for all elements except model, value, label, submission, mediatype, filename

<John_Boyer> so it's really just "associate"

Leigh: Let's discuss Charlie's idea of use cases next time.

Charlie: In terms of Steven's "sheets"

<Steven> It's not a metaphor, it's an analogy! :-)

<wiecha> sorry

synedoche or metonymy

Summary of Action Items

[NEW] ACTION: John_Boyer to write up first spec text for context everywhere, context on bind elements [recorded in http://www.w3.org/2009/06/11-forms-minutes.html#action01]
[NEW] ACTION: nick to work up xpath 2.0 as optional for dot release of XForms [recorded in http://www.w3.org/2009/06/11-forms-minutes.html#action02]
[NEW] ACTION: Nick to write spec ready text for an xpath function that creates nodes (elements, attributes) [recorded in http://www.w3.org/2009/06/11-forms-minutes.html#action04]
[NEW] ACTION: Steven to write spec ready text for adopting XML Events 2 in XForms 1.2 [recorded in http://www.w3.org/2009/06/11-forms-minutes.html#action03]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009/06/11 20:03:56 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/sped/spec/
Succeeded: s/accepted/modified/
FAILED: s/iisues/issue/
Succeeded: s/issues/issue/
Succeeded: s/too/to/
Succeeded: s/I think/John: I think/
Succeeded: s/descent/decent/
Succeeded: s/big/too big/
Succeeded: s/very/most/
Succeeded: s/as well//
Succeeded: s/Eric/Erik/
Succeeded: s/calculate/recalculate/
Succeeded: s/there's/there are/
Succeeded: s/nd/and/
Succeeded: s/such//
Succeeded: s/cas/case/
Succeeded: s/Uli/Erik/
Succeeded: s/model/idea for subsetting models/
Succeeded: s/words/worms/
Succeeded: s/machiner./machinery./
Found Scribe: Charlie
Found Scribe: wiecha
Inferring ScribeNick: wiecha
Found Scribe: nick
Inferring ScribeNick: nick
Found Scribe: wiecha
Inferring ScribeNick: wiecha
Found Scribe: Steven
Inferring ScribeNick: Steven
Found Scribe: klotz
Inferring ScribeNick: klotz
Scribes: Charlie, wiecha, nick, Steven, klotz
ScribeNicks: wiecha, nick, Steven, klotz

WARNING: Replacing list of attendees.
Old list: John_Boyer Steven [IPcaller] wiecha unl kenneth ebruchez
New list: kenneth wiecha John_Boyer ebruchez nick unl Steven Leigh_Klotz

Default Present: kenneth, wiecha, John_Boyer, ebruchez, nick, unl, Steven, Leigh_Klotz
Present: kenneth wiecha John_Boyer ebruchez nick unl Steven Leigh_Klotz
Regrets: None
Agenda: http://www.w3.org/MarkUp/Forms/wiki/vFtF_2009_06_11
Got date from IRC log name: 11 Jun 2009
Guessing minutes URL: http://www.w3.org/2009/06/11-forms-minutes.html
People with action items: john_boyer nick steven

[End of scribe.perl diagnostic output]