<John_Boyer> Scribe: Charlie

<John_Boyer> scribenick: wiecha

John: emails went out with agendas for upcoming couple weeks...pls comment

<nick> I took the liberty to write something up for the Case Function

Data-driven Switch and case() function

John: both have interest and/or implementations

<Steven> "The forms you use in a US post office are produced with XSL-FO and XForms; your bank statement may have been produced with XSL-FO."

John: on data-driven switch, we've talked about this in the past and there's a recent email thread with some new ideas

<Steven> Just saw this today

John: previously we talked about an element child of switch, with SNB, called it "using" for lack of better name at the time
... also talked about another attribute on switch element, with xpath value
... only downside to using attribute is by comparison with element don't have opportunity to use @bind for IDREF for xpath
... with child element have full set of binding attributes available

<nick> MarkB propose:

<nick> <switch>     <selected value="if(name='John', 'B', 'A')" />     <case id="A"> ...</case>     <case id="B"> ...</case>     <case id="C"> ...</case>     <case id="D"> ...</case>   </switch>

John: I pointed out on the list that @value doesn't create two-way binding (full SNB behavior)
... data-driven behavior goes in both directions -- i.e. switching case using toggle drives data back into instance as well

Nick: i like option of using @value if you want only 1-way binding

<nick> <switch>     <selected ref="my/case" />     <case id="A"> ...</case>     <case id="B"> ...</case>     <case id="C"> ...</case>     <case id="D"> ...</case>   </switch>

Leigh: what does it mean to use selected value? could be conflicts between toggle action and data binding values

John: yup, toggle might have to be no-op in that case

Leigh: also what if selected node is read-only?

John: yup, that's a comment about use of SNB
... I have an impl with foreign-namespaced attribute where we handle these cases
... if you try to toggle case and it has this binding, looks at node, if read-only, toggle no-ops

Leigh: but no way for trigger issuing toggle to know
... i.e. no way to give feedback to user

Nick: some impls can tell if binding is read-only

John: it's computable

Charlie: but inconvenient

John: also can use setvalue instead of toggle, goes to readonly node, will fail...same issue
... topic on agenda for two weeks from now to talk about extending xforms to allow authors to query MIPs using xpath
... would help here

Leigh: yes, but would be nice to do declaratively
... what about trigger and R/O refs?

Nick: unavailable then

Leigh: then could bind trigger to R/O node
... same node as switch is looking at

John: oops, we went other way in trigger behavior

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

John: R/O MIP does not affect whether trigger can be activated
... would need @if...

<John_Boyer> <action ev:event="DOMActivate" if="not(model-property('readonly'))">

Charlie: but this sounds like what the author would want as default

<John_Boyer> separate discussion about function for model-property because it might be hard to get dependencies for such a function

<nick> Hmmm, we make the trigger disappear when not relevant, and read-only when the the node is read-only....

John: if instead of SNB we used @value this could work as long as toggle has no affect on switch if the switch was using @value
... should we back up to R/O trigger behavior?

Leigh: April 29th, 2007

<klotz> http://lists.w3.org/Archives/Public/public-forms/2007Apr/0046.html

<klotz> http://lists.w3.org/Archives/Member/w3c-forms/2007JanMar/att-0219/20070321-3.html#ACTION3

John: seems like disabling trigger when R/O is the preferred behavior
... back to data-driven switch...
... what if author does setvalue to node with value that fails to match any case in the switch?

Leigh: switch is out-of-range

John: yes, but which case should be selected
... in our case (sorry) we said that was ok, and we'd fall back to the default specified on the case elements
... want the behavior to be reliable

<Steven> What happens if we toggle a non existent id value?

John: e.g. if save the data and reload into fresh form template...not reasonable to say if you change the value of the node to non-matching node the switch should just stay "where it was"...that's not preserved across save and reload

Leigh: might not be a @default...so perhaps none of them should display

Steven: +1

John: acceptable to me...it's stable across save/reload

Leigh: need to decide if you have both instance value and @default

John: data-driven version should override...same as behavior of switch now...runtime toggles change cases

Leigh: if you start with instance of empty string and valid @default...or non-matching instance but still have @default...

John: right, but never let default drive the data
... by virtue of opening the document the data should not change...that's broken
... unless there's an explicit action

Leigh: when would the @default be used?

John: when data is out of range
... selected construct binding to data override @selected on cases

Leigh: getting close to the behavior for select/select1
... could do the same thing for out-of-range for switch/case

Nick: might be confusing to have the switch be completely gone if out of range

John: if instance starts out empty...driving the switch w/o data is not a good idea...
... so first question is: do we want @value or SNB approach?

Charlie: SNB

Leigh: binding

John: comes with a few more "qualifiers"
... there is a behavior for toggle with these types of switch
... as child element or attribute that's next question
... but still not same as SNB on form control
... don't dispatch all refresh events to this element in same way as label/hint/alert don't get them
... actual controls have more behavior
... same as xforms actions having SNB

Leigh: do we need to drill down further into events etc?

John: don't think so...above was clarification that SNB here is like those other examples
... child element or attribute?

Charlie: both

<Steven> I vote for attribute

John: advantage of child elements is you can use @bind

<Steven> ah yes, bind

<Steven> good point

<nick> I'm in favor of a selected child with ref and bind attributes

Charlie: why not allow short-hand w/attribute or long-hand with element?

<Steven> +1 to both

<kenneth> +1 to attribute

John: Mark suggests attribute/element pair but where overriding element uses @value
... we can separate those decisions

Kenneth: I'm ok w/ having both

John: anybody opposed to both?

<klotz> both sounds fine to me

Uli: don't know why we need extra attribute
... we already have attr on switch for relevance

<Steven> Good point Uli

John: good point, extra attribute in our impl is based on idea that switch is container and @ref there is context node for subtree
... @ref there tends to go at subtree not root

Uli: don't find it intuitive to have two SNB on switch...hard to understand

<nick> <switch>     <selected ref="my/case" />     <case id="A"> ...</case>     <case id="B"> ...</case>     <case id="C"> ...</case>     <case id="D"> ...</case>   </switch>

<John_Boyer> <switch ref="paymentMethod" selected="@methodType">

Uli: another point, to set the binding context we could just use a context attribute
... how would @selected be evaluated? in what context? of switch?

John: same as other "secondary" attributes...if there's @ref then that context controls context for other attributes
... so having child element as override gives chance to use bind sites in addition to xpath

Uli: ok, sounds good to have both

John: ok sounds like we have consensus on using both
... next question is name...
... don't know why "selected" didn't come up
... perhaps concern about confusion with case element @selected

<nick> +1 for selected

+1

<unl> +1 for selected

<John_Boyer> +1 for selected

Leigh: checking past discussions about possible reasons for not using @selected
... think that was more related to changing it to boolean on case
... sounds ok to me

<unl> s/shoen/schön/

John: ok, sounds like it's @selected

Charlie: element too?

John: matching element and attribute yes

<scribe> ACTION: John_Boyer to write up selected attribute and child element with SNB for data-driven switch, overriding selected attribute on case [recorded in http://www.w3.org/2009/06/18-forms-minutes.html#action01]

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

Case Function case()

<nick> http://www.w3.org/MarkUp/Forms/wiki/CaseFunction

John: think there are impls already
... understand takes parm of ID of the switch, returns ID of selected case if there is one
... given data-driven switch, there's a possibility of no selected case, would return empty string

Nick: i have an example
... based on orbeon impl

John: what's the return value...xs:string?

Nick: related to returning empty sequence
... more info than empty string

John: for xpath 1.0 it would be just string

Nick: yes

John: namespace qualified the case fn?

Nick: yes
... need to discuss
... should fns keep going into global if we're heading to xpath 2.0

John: does xpath 2.0 allow to set default ns?

Nick: yes

<nick> http://www.w3.org/MarkUp/Forms/wiki/XPath_2.0

Nick: yes, we could set default to us, then have to qualify all the std fns

John: painful

Nick: discusses collisions between xforms and xpath 2.0 and diff behavior

John: makes me wonder if we should say for xpath 1.0 we continue as now, but for xpath 2.0 our fns are only accessible in xforms NS

Nick: yes, would be good

John: if using xpath 1.0, case() should be same location as index()...but for xpath 2.0 would have qualified name
... gives freedom to treat XForms for HTML continue to be based on xpath 1.0
... w/o qualified fn names
... (...missed point about dependencies)
... index() acts like it creates "false" instance data
... so xpath expressions w/index() have correct dependency tracking

Charlie: so case() should do the same?

Nick: will check for this behavior and also for no-cases selected

<scribe> ACTION: Nick to write up delta spec text for case() function in xpath 1.0 style and covering dependency behavior [recorded in http://www.w3.org/2009/06/18-forms-minutes.html#action02]

<trackbot> Created ACTION-555 - Write up delta spec text for case() function in xpath 1.0 style and covering dependency behavior [on Nick Van Den Bleeken - due 2009-06-25].

John: also good to cover both xpath 1.0 and 2.0 behaviors
... will need in general for all fns going forward

Dialog

Leigh: Erik has implementation

John: have had difficulties in the past with putting UI controls in the dialog and event bubbling questions

<ebruchez> sure ;)

John: could discuss a new element, e.g. dialog, containing UI content but referenced from actions or elsewhere
... UI is referenced not inlined
... no confusion about event flow

<nick> or actions to show and hide a dialog, like it is done in Orbeon

Charlie: would it be useful to have events bubble out of that context? even if separate

Erik: reviews example

<ebruchez> <xforms:dialog>

<ebruchez> <xforms:label>Title</xforms:label>

<ebruchez> ...

<ebruchez> </xforms:dialog>

declarations usually at the top level of the document...separate from executing UI

scribe: e.g. under body

John: could see using this inside repeat as well

Erik: yes, could do that
... one action to open dialog, another to close

xforms: show dialog="IDREF"

<ebruchez> <xforms:show dialog="my-dialog"/>

<ebruchez> <xforms:hide dialog="my-dialog"/>

John: is dialog modal?

Erik: have attributes to control that, also on the action

<nick> on dialog appearance="full | minimal" level="modeless" close="true" draggable="true" visible="false"

Erik: want to prevent interactions with content under the dialog...hard to implement in underlying js frameworks...block events etc
... if you want modal behavior
... can close either with built-in close icon or with trigger calling xforms;hide

<ebruchez> xforms-dialog-close and xforms-dialog-open

Erik: similar to toggle
... dispatched to dialog

Charlie: do events bubble out of the dialog?

Erik: yes

John: how's that going for you?

Erik: ok, since dialogs are at top level of doc
... might be interesting if dialog is inside repeat

John: trouble in the past with event flow was more with UI content inside of message action inside of trigger...DOMActivate bubbling back up to the trigger
... trying to close the dialog might re-show the dialog
... so separating dialog declaration from invocation solves this problem

Erik: yes, but if you have a very simple dialog would be convenient to put directly in the action...but in most cases they're complex enough to warrant separating them from where used

John: also, the act of closing the dialog probably doesn't generate a DOMActivate?

Erik: right, uses underlying behavior

<nick> I really like how it is implemented, the only thing that requires some coding is a dialog with an ok and cancel button, because you need an extra instance, and copy between the instances on show and when the OK button is closed

Charlie: what about nick's point of data binding?

Leigh: yes, what about communication between models or instances?

<klotz> and transclusion via src

Erik: related to that point, we have flexibility in our impl to scope our model within a dialog
... dialogs often warrant having own instance data, submission, binds etc
... don't need to actually nest the model in the dialog to do this
... for packaging we allow putting the model inside the dialog itself
... encapsulated function
... we can set custom context information in show and hide actions so can pass info on invocation

Charlie: could you please provide example?

Leigh: people also want cancel operation

Nick: need to copy in and out...lots of coding

Leigh: yes, perhaps "submit" back up

Erik: yes, these patterns suggest local data...but copying data in is easy with context info passed in
... dialog has open event listener to insert that data into local instance
... passing data out is a bit harder if you want the dialog to be completely reusable...need destination location

John: in the past we have had need for equivalent of @ref but subtree binding
... to support subtree replacement
... when dialog was activated it would bind to subtree
... on "hide" that's a signal to commit data back to external subtree by replacement like submission replacement

Leigh: relates to submission as well

Charlie: also a question of whether binding is live during dialog execution

Erik: XBL speaks to all this
... preferred way to sync w/shadow tree is by events

Charlie: there's also attribute binding

Erik: our dialogs are not this complex

<John_Boyer> for a modal dialog, show and hide are good communication points. For modeless dialogs, a more incremental binding is probably desired

<John_Boyer> perhaps with more events

yup

<John_Boyer> like dialog-commit event

<John_Boyer> default processing does the copy from dialog internal data to the bound subtree

we could in 1.2 do the simple case of application level data input/output and generalize with the components theme longer-term

Nick: pattern of ok/cancel with subtree is very common...need an easier way than application level code

John: ref method would be short-hand for two-way automatic communication to happen by default
... could be overloaded with custom event scheme when needed

Erik: for custom controls in general there's a problem with a component separating internal processing from synching with external instance

Charlie: yes, that's why i was thinking we deal with these aspects of dialog later along with the custom control theme

John: for atomic controls in our impl we have more declarative means to describe formatting as layer around XForms behavior
... separates custom control behavior from data binding behavior
... w/o event handlers...it's automatic behavior

Charlie: so perhaps we can scope the function to deal with the simple subtree read/replace case now and expand later

John: declarative templates for formatting get hard when there are composed values...not single atomic field
... either at UI or instance level
... like inline dialog

Erik: yes, that's the point...we have the same problem with composites
... complex types

Leigh: would it support different source and destinations?
... so putting separate refs on invocation to initialize and on the dialog to say how to return values would support this

Erik: but the dialog shouldn't itself know where

Charlie: the dialog needs to specify the "type" not the destination

Erik: the separation of submission from send is also problematic
... so our show and dialog is a bit closer
... so submission is more an example of how we don't want things to be

Charlie: wasn't saying they should be on same element, just that there are *two* concepts
... destination and structure

Leigh: dialog lifecycle is like an internal version of submission

<ebruchez> I like Leigh's xforms:domination

Leigh: Raman and Leigh talked about "component" and "use" but never got too far

John: so you're talking about submitting *to* the dialog

<John_Boyer> so just to sum up, you're talking about a submit or trigger that invokes a send,

<John_Boyer> that then calls a submission.

<John_Boyer> the submission resource would indicate the dialog

<John_Boyer> the submission ref describes input to the dialog

<John_Boyer> and the submission targetref says where to put the result of the dialog

<John_Boyer> Leigh: Yes, except it doesn't have to literally be those elements. That's just the model. The dialog is an "in the box" web server

<John_Boyer> Now we're breaking for breakfast/lunch/dinner

<John_Boyer> when we come back, will continue with dialogue on dialog

<John_Boyer> Scribe: Nick

<John_Boyer> scribenick: nick

Leigh: Dialog is the dual of submission

John: Dialog is a UI element

Leigh: Which is a component where you can submit to and return from

Charlie: The input and the output could be diferent

John: Now we have only simple bindings, in the future they could be different

Erik: As we implemented could have SNB

<John_Boyer> q

Erik: We can use setvalue ...

Nick: It should be possible that the caller decides which data is edited, bcz there could be more callers

Erik: We solved this by using events

<xf:show input-ref="..." output-ref=".."/>

John: We can do this with submission, by first doing a setvalue

Erik: In our implementation we could set the context info of the submit-event to override the submission parameters
... ... explains that using something like a ref on the show dialog actions will complicate the bindings of the form controls in the dialog
... Dialog can behave as non relevant groups when not visible and as a relevant group when shown. Ok then it isn't that different

John: It is more like repeat, bcz. the dialog can be shown multiple times with different contexts

<klotz> http://xformstest.org/klotz/2009/06/ftf/component.xml

Erik: We need to decide that that is needed

John: If the dialog has a ref with event() you could reference the context for more advanced stuff
... With a simple ref you could update the subtree

Leigh: We need dialog and a component

John: We could accomplish a simple dialog by a switch with one case and when not shown nothing is selected

Leigh: We could do it separately and let everything work together (components, dialogs, submissions)
... in a declarative way

Erik: You want to instantiate it multiple ways
... Leigh your re-inventing a lot of XBL

Leigh: I want to look if we could do it with events, but our submissions are also sort like events

John: Could you fill out the submissions more so we can see where the data comes from and goes to

Leigh: That needs to be worked out more

John: Can we sort this out by letting two models talk to eachother

Leigh: You can by using events

John: You can't set event context without using extension
... Using events for communicating between models

Erik: We can do this by variables in our implementation
... I fear that it will take a very long time to finely define how components can communicate, and I'm not sure that we need to do this now

John: The dialog that you have today, can be seen a component with submissions

Erik: You could implement dialog using components

Leigh: I think it is reasonable to do it now

<John_Boyer> The dialog could have a default component that is implied if you don't express the component and submissions.

Erik: There are a lot of different 'kind' of dialogs, and there are many complicated components available off the shelf, and it is hard to specify how they should be expressed in markup. We should add a mechanism to use these components in XForms be defining a generic component framework
... We accomplished this by using XBL

Charlie: Are we switching to components?

Erik: If we have the component framework we don't have to specify dialog, but dialog could be in a standard component library

John: I want to have a dialog, but it also make sense to put the dialog in a component to support two way data flowing

Leight: I only did one way, the way in the component

Leigh: I want to keep the dialog simple

Erik: I also think we should keep it simple

<John_Boyer> <dialog ref="some tree"> ... <trigger><label>OK</label><hide ev:event="DOMActivate" commit="true"/></trigger><trigger><label>Cancel</label><hide ev:event="DOMActivate" commit="false"/></trigger></dialog>

Leigh: We should have a simple dialog, and be able to wrap something around it to do the data-mapping and support OK and Cancel

<John_Boyer> component could wrap around this and the dialog ref could bind to the component instance

Erik: I want something simple, similar like switch

John: agrees that it should be kept simple, and refers to the markup he pasted

<John_Boyer> show makes a copy of referenced tree, hide either does nothing or replaces

Erik: Would this create an implicit data instance, and do the copy back on OK

Leigh: Dialog should have the same semantics as group, and commit='false' bothers me, I don't want an internal copy, that is a component

John: Agrees, ref just references the node, and the application should do the cancel them-self

<John_Boyer> and "the application" could be improved by having a component construct to wrap around dialog

Erik: Simplicity is crucial

Charlie: Do we want to support multiple invocations of dialogs simultaneously?

John: It is something that comes from component
... The realisability should be defined in components
... Dialog is similar to group you can't reuse a group either

<ebruchez> Hixie on dialogs in HTML 5: http://www.webstandards.org/2009/05/13/interview-with-ian-hickson-editor-of-the-html-5-specification/

<ebruchez> Bruce

<ebruchez> What’s your fave feature that didn’t get into HTML 5 that you’d put into HTML 6?

<ebruchez> Hixie

<ebruchez> In-window modal dialogs or dialog box—the kind of prompt you get when the computer asks you a question and won’t let you do anything else until you answer the question. For instance, the window that comes up when you say "Save As…" is usually a modal dialog.

<ebruchez> Right now people fake it with divs and complicated styles and script. It would be neat to just be able to say "make this section a modal dialog". Like showModalDialog(), but within the page instead of opening a new window with a new page.

<ebruchez> I’d add it to HTML 5, but there are so many new features already that we need to wait for the browsers to catch up.

Leigh: We need both dialog and components.

Charlie: I'm happing to let it go

Everyone agrees that we should keep dialog simple

John: Dialog is similar to group

Erik: Is as simple/complex that we implemented it
... You don't have to pass custom context info to show a dialog, but you can pass the custom data

<ebruchez> http://www.w3.org/MarkUp/Forms/wiki/PassingEventContext#preview

Erik: you could use the in-line context but additionally pass extra context info to the show action that is provided when dispatching the event to show the dialog

<ebruchez> <xf:show dialog="fb-confirmation-dialog">

<ebruchez> <xf:context name="my-message">Are you sure?</xf:context>

<ebruchez> </xf:show>

<ebruchez> <xf:dialog id="fb-confirmation-dialog">

<ebruchez> <xf:action ev:event="xforms-dialog-open">

<ebruchez> <xf:setvalue ref="..." value="event('my-message')"/>

<ebruchez> </xf:action>

<ebruchez> </xf:dialog>

Erik: Explains the example that he just pasted

<klotz> <xf:subform><xf:instance value="event('my-message')" />...</xf:subform>

talking about the problem <xf:dialog ref="event('my-paylod')>...

<Steven> scribe: Steven

Dialogs [cont'd]

rrsaent, make minutes

ha

<nick> I would propose to use the 'simple' approach of Orbeon

Charlie: Without the refs Nick?

Nick: [scribe missed]

<John_Boyer> Nick says optional ref on dialog but not able to ref the event function

<nick> The dialog with a simple ref to a node, not supporting ref="event('payload'")

John: Then we have gone through the possibilities, and all the complications in components, and end up with something simple
... Who will write it up?

<nick> If Erik wants to do it, he can do it, otherwise I can try to do before next call

<scribe> ACTION: Nick to write up dialog[ue] first draft [recorded in http://www.w3.org/2009/06/18-forms-minutes.html#action03]

<trackbot> Created ACTION-556 - Write up dialog[ue] first draft [on Nick Van Den Bleeken - due 2009-06-25].

ue=user experience version

<klotz> message

John: What does dialog give us that grouip/switch doesn't?
... I think that it is being invoked

Erik: And presentation issues

Nick: More declarative

<John_Boyer> Nick: and extra eventing

Erik: It would be great to have more implementation feedback

Application requirements for external models and sub-models

John: We should identify the requirements that we want to solve
... we talked about @src on model, as a way of getting model content from somewhere else
... which then ballooned based on use cases
... what do we want to achieve?

Steven: From my point of view it is about encapsulation
... defining the model once, and using it from different places

Charlie: for some apps, you may need two models with the same features

Nick: The second is components

Erik: Simple inclusion means a single DOM, which has problems with id resolution
... and the other is like how we deal with imported instances
... simple inclusion is easier to do

Charlie: I want to question the second use case
... the inclusion mechanism would satisfy Steven's use case
... but not the second

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

<klotz> you could also include the model and parametrically interact with it via internal submissions, making it a REST adapter to an external service

Erik: We parameterise external models via different mechanisms, including events
... which gives reuse, and works perfectly with plain inclusion

John: Never mind solutions for now
... stick with use cases
... see link above
... can we flesh that out?

Charlie: I had a web service example
... where I wanted to isolate details
... but hook up with the user interface

Leigh: I think it's a generic Web services adapter

John: Is encapsulation different from reusability?

Charlie: Yes.

Uli: Encapsulation is needed for reuse, but doesn't force it; just enables it

Charlie: XInclude is not encapsulation, just lexical separation
... there's no abstraction

<unl> XInclude is just a means to /achieve/ encapsulation

Erik: We use IDs too much in XForms
... XSLT avoids this

Steven: I said the same a couple of weeks ago
... we wouldn't have feared the switch in repeat problem if we hadn't used ID
... but we were trying to be good XML citizens, and so were frozen

John: Is it useful enough to just refer to the whole model and nothing else?

Charlie: I think so

John: Why would you need to do that?

<klotz> <model src="messages.xml" /> <!-- Accept-Lang --> ... <xf:input ref="po-name"><xf:label bind="purchase-order-name"/>...

Steven: For instance if I want to access multi-lingual messages, and I don't want the form to reflect any details of the structure of the data
... ot a tax form that imports a tax model, with its binds

<klotz> <model src="messages.xml" /> <!-- Accept-Lang --> ... <xf:input ref="po-name"><xf:label bind="purchase-order-name"/>...

<unl> <xi:include href="messages.xml" accept-language="en"/>

<model id="messages"src="messages.xml"/>

<select1 bind="langchoice">....

<input ref="..."><label bind="yourname">...

Steven: This allows a central authority in my company to control labels, and translations, and add new languages
... and all forms that use it will get updated with new languages as they are introduced, with no extra work
... and no dependency on the internal structure of the messages instance

<ebruchez> clonk

John: So we have uses for that
... cool
... and now there are two or three ways of saying I want to include parts of a model

Steven: After I proposed this, you John added a need to decorate an imported model

ach char

<nick> ack [IPc

<unl> MarkB outlined another use case: http://lists.w3.org/Archives/Public/public-forms/2009Jun/0056.html

Charlie: Where you have a centralised manage model, like for a purchase order
... I would to import a model and then specialise it
... by adding binds for instance
... and then another case
... a webservice model, that knows how to talk to a web service
... that I want to pipeline in a series of models that transform the data
... (accepting for now that we don't support inter-model communication)

John: The main model of a form has the main data payload
... but along the way, some webservices may have given me some behaviours, like form pre-filling

Charlie: I'm talking about the adaptor pattern

[Some editing of wikipage follows]

http://www.w3.org/MarkUp/Forms/wiki/ModelEnhancementRequirements

John: I understand that the service invocation is different from the data I expose in the UI
... So in fragment inclusion

Charlie: I think that is what I meant by specialisation
... not for different roles

John: If I have a multi-page set of transactions
... I am worried that on the first page that certain constraints won't be meetable

Nick: You could use a switch

Erik: Multiple pages are the old way of doing it, because you had to
... but they are being used less

Steven: I don't see how this relates

Nick: You can do it with relevance

Charlie: This is a variant of the adaptor pattern
... I think there is a model to model communication going on

Nick: But why in multiple pages?

Charlie: Performance

John: I'm not convinced the master model needs to be around

<nick> scribe: nick

John: Often on the server side you have to schema validate the whole model

Charlie: Is there an automatic way to create the submodels for the 50 different pages from the parent model

John: Maybe it is just that every page re-uses a small model on all pages and augments it differently for every page

Charlie: I would only support narrowing down the constraints

Leigh: How do you make the specialized model for the pages

John: One model includes different model fragments containing instances, binds, submissions
... without nesting

Charlie: It should be authored in a special way, because you can't relax constraints

John: Next use case: Fragment Reusability
... multiple times in same page like an address block
... Example pull in a set of binds for a reusable fragment
... Are there technical problems

talking about id conflicts when including whole models

<John_Boyer> Do current XInclude implementations provide a mapping which says "I turned [X,Y,Z] into [X1,Y1,Z1]"

<John_Boyer> ?

the problem is when two models use the same id's when they are put together in a single document, we now in the UI which id's to use because we have extra information about the model to use based on the model attribute

<John_Boyer> XInclude can fix up IDs and IDREFs within the included content, but the included content may contain XPaths with instance() references, so we need the map to do our own additional fixing up

when using XInclude we also have the problem that we use id's in XPath functions which won't be corrected by a standard XINclude engine

when using XInclude we also have the problem that we use id's in XPath functions which won't be corrected by a standard XINclude engine

so it also feels a bit like components...

We need to talk about it further, but we will discuss some other items first on the next call

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/may/will/
Succeeded: s/tiger/trigger/
Succeeded: s/toggle as/toggle has/
Succeeded: s/tant/tent/
Succeeded: s/handler//
Succeeded: s/Goo/Good/
Succeeded: s/binding attribute/context attribute/
FAILED: s/shoen/schön/
Succeeded: s/orbean/orbeon/
Succeeded: s/node/subtree/
Succeeded: s/and I/and Leigh/
Succeeded: s/of the shelf/off the shelf/
Succeeded: s/Dialogues/Dialogs/
Succeeded: s/compents/components/
Succeeded: s/lanh/lang/
Succeeded: s/couldn't/can't/
Found Scribe: Charlie
Found ScribeNick: wiecha
Found Scribe: Nick
Found ScribeNick: nick
Found Scribe: Steven
Inferring ScribeNick: Steven
Found Scribe: nick
Inferring ScribeNick: nick
Scribes: Charlie, Nick, Steven
ScribeNicks: wiecha, nick, Steven
Default Present: wiecha, John_Boyer, Leigh_Klotz, Steven, unl, kenneth, ebruchez, nick
Present: wiecha John_Boyer Leigh_Klotz Steven unl kenneth ebruchez nick
Agenda: http://www.w3.org/MarkUp/Forms/wiki/vFtF_2009_06_18
Got date from IRC log name: 18 Jun 2009
Guessing minutes URL: http://www.w3.org/2009/06/18-forms-minutes.html
People with action items: john_boyer nick