<Steven> niente

<John_Boyer> Scribe: Steven

Steven: I will be returning late after the break; I will try to return ASAP

kenneth

<John_Boyer> Erik

�

�

Solutions for the Application Requirements Related to the External Model and Submodel Problems

Nick: I talked with Joern, and he agreed with what we were talking about yesterday

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

John: I documented our requirements from the last call
... We got to basic use cases around encapsulation
... next is a specialization model
... model content that could be used as a base
... and then further specialized
... one of the later examples (fragment inclusion) could be solved with a specialization capability
... the third case was the adapter concept
... with two sub points
... the second that I list (transforms) - is that a true adapter, or is it more of a specialization?

Charlie: The UI case needs extra instances, so it is different

Leigh: I thought you meant overriding binds with specialisation
... you don't need anything more than XInclude

John: I think we ended with specialization not contradicting any binds in the base model

Leigh: We should make that explicit

Charlie: If something is read-only in the base, I would expect it not to be overrideable
... I think we should be able to collapse specialization and adapters
... into one

John: I think fragment inclusion collpases into that too
... which is really exciting
... The specialization pattern is including once and adding stuff
... the web services case is about multiple external inclusions

Charlie: The webservices includes new submission methods, but the others don't

John: Maybe 'adapter' is misnamed

Charlie: You don't need extra submissions when you are adapting the UI

John: Specialization treats the input like a pipe

Charlie: Prefilling pulldowns in a select
... so there may be more needed in the UI case than I thought

John: What does live in the base model?

Charlie: The further we go, it sounds more and more like model to model binding

John: The backend data lives in the base model
... The base model contains the submission for getting the data back to the service

Charlie: Let's assume that for now

John: On the specialization side, there would be a need for actions in the specialization to copy the data to and fro
... what characterises the moving of data back to the backend?
... what would trigger it?

Charlie: A submit?

John: A specialisation needs to include an action handler for xforms-submit that would be dispatched to the base models submission element.
... That element knows how to move the back-end data to the server
... So we've proven we need instances and actions in the specialization

Charlie: Structural calculations will help

John: Specialization is one means of achieving a UI transformation
... but structural binds would be more declarative
... If we were to do structural binds, how do we get two-way communication?

Steven: We don't have two-way now

John: Do we mean 'binding' or structural synchronization?

<nick1> you need to watch out for rounding errors

Steven: I believe that you can get two-way now by using binds in both directions

<John_Boyer> Similar to simple data synchronization that Steven mentioned a few years back, e.g. Fahrenheit and Celsius conversion

<John_Boyer> If you type Fahrenheit, it calculates Celsius and vice versa

Steven: But you have to handle cycles yourself

Charlie: You can check for equality to stop cycles

Steven: It is still possible to flip-flop between two close values (for instance using multiply and divide)

Charlie: It could get even harder with structural synchronization

Steven: Not sure about that. The ways a structure can change are limited

John: We may be able to address the base cases, without having to deal with the general case of breaking cycles
... Back to the adapter/webservice case
... you might have a base model that does a lot of the work
... containing the raw data, and knowing how to talk to the server
... it's not doing a UI transformation of the core data
... with webservices, the issue is multiple small services being invoked during interaction, in order to enhance the user experience
... such as name expansion
... or postal code lookup
... if these are generic things that can be invoked in different forms
... then that should be possible

Charlie: You can think of an adapted form as a type
... the problem is gluing the parts together
... Think of a library of components

<John_Boyer> The UI adapter could be viewed as another composable component just like Web service XForms markup for multiple services would be composable components

Charlie: Maybe it's not worth going that far yet
... Treat the whole UI as a component
... since it is a reusable artefact
... that jump is a bigger step
... maybe consider it later when we get to components

Leigh: We should pay attention to model when we consider WSDL

John: If we had a way for models to communicate

Leigh: With events, then make it look like a webservice

Steven: I think the idea of in-form submits is a very interesting one

Charlie: Are simple controls just a simplified in-form submit?
... allows lots of extension points

Focus on Submission Improvements

<scribe> Scribe: Charlie

<scribe> scribenick: wiecha

John: have broken up rest of day into a set of related discussions
... right now @method on submission is required
... don't think we allow computing the method

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

John: actually, we do have method element with @value
... so @method is not required, but we don't have a default for the submission method however specified
... so perhaps we should state some default

Leigh: used to have "get" as default but was removed

<nick1> we use post most...

<nick1> because we use XML

Steven: we were asked to deprecate get at one point
... XForms 1.0 states no default for @method

John: which edition? guess first edition starts out with that
... any objection to setting method="get" as default?

+1

<John_Boyer> +1

Erik: no objection

Steven: starts out from 1st edition in 1.0

John: if no objections then we need an action item for next edition for xforms
... btw, need to discuss editor(s) for 1.2
... nominations?

<nick1> I can be an editor...

<nick1> but now I have time, the problem is that it is hard to guarantee it for the future...

<Steven> post was the default in January 2002, and there was no default in aug 2002

<scribe> ACTION: nick to prepare update to 1.2 spec to reflect default for @method="get" [recorded in http://www.w3.org/2009/06/25-forms-minutes.html#action01]

<trackbot> Created ACTION-558 - Prepare update to 1.2 spec to reflect default for @method="get" [on Nick Van Den Bleeken - due 2009-07-02].

John: moving to more control around RRRR on submission completion and/or initialization
... in particular to suppress them on sequences of submissions
... authors have found performance problems with multiple sequential submits, e.g. to web services
... in 1.1 have recently simplified things via sync submissions since UI refreshes are skipped, but still do rest of the cycle which is costly

Charlie: maybe could scope the RRRR over a specific instance

John: we do say the behavior must be "as if" the full rebuild takes place

Leigh: could lead to interop problems

<John_Boyer> If you do a setvalue followed by a send (submission), if the setvalue changes a bind nodeset predicate, then it matters whether the submisison does a full rebuild or an "optimized" rebuild that only accounts for the changes made by the submission instance replacement

<John_Boyer> Leigh made the above point

Erik: need to recall the original requirement for doing RRRR on submission
... validation, also calculate, but primarily validation
... perhaps there's a use case for turning off validation via attribute on submission

<John_Boyer> This suggests it would be better to have explicit control over whether a submission does rebuild-recalculate-revalidate on submission initialization and [R]RRR on completion

John: turning off validation doesn't necessarily suggest we can skip other stages, e.g. rebuild

Nick: is the use case multiple submissions at once?

John: that's the original goal, might be other reasons

Nick: if you do the first one of a multiple set, and the submit replaces some data an impl can decide what can be skipped in rebuild etc
... before doing next submission

John: on completion?

Nick: yes, before doing next submit
... e.g. can skip binds that refer to other instances than the one modified by returned values

John: though Leigh's point shows any intervening actions can in general cause problems

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

John: on init it's only rebuild/recalc that are triggered by deferred update, revalidate in step 4 happens regardless of deferred update if flag is true
... so authors have control over revalidate, could use similar for rebuild/recalculate
... on completion instance replacement happens according to insert/delete operations, text replacement by setvalue semantics
... so submission doesn't have direct control over those post-receipt behaviors...could have indirect control by claiming those operations are not outermost
... in a sequence, if the first submit is async then when it completes you do setvalue/insert/delete then do 2nd submission...i.e. a sequence of submissions with other operations in between
... doesn't really depend on async
... could get better performance in general by suppressing these steps

Nick: just concerned if this is for performance then requiring the author to set a bunch of flags doesn't seem right...would be better for the impl to be able to optimize on its own

Erik: yes, also there's a diff w/recalculate and relevant attributes on submission now. these are not performance related

Nick: yes, these are processing steps that are functional issues for the author, not simply performance
... would prefer impl do optimizations not author

John: problem is it's difficult for the impl to know whether the author wants to optimize or not
... problem is worse when we try to start creating reusable components, e.g. for web service, and control optimization from the point of the invocation
... not the internal defn
... when using singly use normal behavior, when used in conjunction want to use optimized since intermediate results aren't needed

Nick: if someone else creates that service (model) how can they know what to do?

John: perhaps event context info
... parameterize the submission when I call it
... here's some extra info for this specific invocation

Nick: but this seems to imply the user knows the internal impl of the service's invoking component

John: author needs to understand how his changes will affect behavior of the form
... and do regression testing

Charlie: violates encapsulation

John: don't think so...need to know what your binds are doing

Nick: should only depend on the "API"

John: the dynamic predicates are in the consuming model not the web service model
... that's where the broken part is, not in how the web service is invoked
... same problems exist for insert/delete actions in a single model app
... any time we suppress standard behaviors we'll see the same problems

Nick: seems to me we're making it worse

John: so if we scope the web service updates to a separate model we can isolate the required updates
... so perhaps we should drop this RRRR suppression in light of the general model composition issue

Charlie: +1

<nick1> yes, in favor of shooting it

John: moving along to JSON submissions

<Steven> is kenneth here?

John: much more limited form of JSON support than discussed in the past
... this is just import/export in JSON format leaving internal processing in XML
... transform XML or profile of XML into JSON
... and vice versa

Charlie: in general the problem of this transform is hard

John: separate issues around JS expression language etc etc
... would it be useful simply to have two-way communication with external JSON services?

Steven: kenneth has an impl now
... furthermore, the form of the data should be hidden, the structure
... there are other useful representations in addition to JSON, but JSON itself is quite useful for input/output
... would like kenneth to describe how he's doing it

Erik: so it's just JSON/XML conversion?

Steven: think they just read JSON and convert to XML internally

Nick: tried this some time ago didn't find std way to do the mapping

<John_Boyer> Is the conversion automatic only, or does the author have the ability to transform it? Seems automatic would be sufficient because we could write the transform ourselves once it's in XML

Charlie: yes, that's the question

John: might constrain the XML you can express in the instance that is transformable two-ways

<klotz> http://code.google.com/p/xml2json-xslt/

<Steven> I think it's a great idea

<nick1> http://www.json.org/example.html with XML but it isn't a standard mapping as I know

<John_Boyer> Although not all XML is translatable to JSON, it doesn't matter. If you're talking to a json service, you have to write the xml that will translate into something the service understands

<Steven> exactly

<John_Boyer> No different from writing your xml to conform to a schema that a backend transaction processor will be able to proces

Leigh: we have only half of the general conversion problem...we're always starting with XML-> JSON and not vice versa
... so this is easier

John: would be good to also allow script authors to use their trick to get around cross-domain issues
... i.e. a script tag in the web page can talk to other services w/o security limitations
... but XMLHTTPRequest is restricted
... might say, for example, that a web service from domain A can talk to one in domain B

Leigh: we don't have to say anything here

<nick1> http://www.xml.com/pub/a/2006/05/31/converting-between-xml-and-json.html

John: so what if two impls do different things here?

Leigh: not related to JSON
... same issue for XML

<John_Boyer> one hour break time

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

<inserted> ScribeNick: nick1

<scribe> scribe: nick

Enriched Text Content

<nick1> John: We've been talking about mediatype="text/html" on textarea

<nick1> ... maybe not required but an optional feature

<nick1> John: We want user to edit rich text, but doesn't needs to be stored as XML encoded

<nick1> John: Now we only have SNB for a textaere, you aren't able to bind to a subtree so the instance contains xml elements like bold and italic

<nick1> ... and not &lt; and &gt;

<ebruchez> application/xhtml+xml

<nick1> Nick: we use XSL-FO as a format in our processor, binding to a subtree

<nick1> John: John we should just give a list of possible formats

<nick1> Leigh: It will be interesting to see how a voice system will do this

<nick1> Leigh: editing ATOM will be a good use case

<ebruchez> <feed xmlns="http://www.w3.org/2005/Atom">

<ebruchez> <title type="text">dive into mark</title>

<ebruchez> <subtitle type="html">

<ebruchez> A &lt;em&gt;lot&lt;/em&gt; of effort

<ebruchez> went into making this effortless

<ebruchez> </subtitle>

<nick1> John: text/html wouldn't ensure the content is well formed XML which we can't support

<ebruchez> <content type="xhtml" xml:lang="en"

<ebruchez> xml:base="http://diveintomark.org/">

<ebruchez> <div xmlns="http://www.w3.org/1999/xhtml">

<ebruchez> <p><i>[Update: The Atom draft is finished.]</i></p>

<ebruchez> </div>

<ebruchez> </content>

<nick1> John: but drawing the line at XHTML should be good

<John_Boyer> So, XHTML means edit XML as XML without encoding, and text/html content would be encoded

<nick1> Erik: Explain the ATOM markup he pasted in the IRC (first type text encoded, type xhtml not encoded)

<nick1> Erik: Orbeon does what ATOM proposes

<nick1> John: Where do we specify the format?

<nick1> Erik: we could use the media-type attribute on textarea

<John_Boyer> Is it appropriate for the UI control to specify the format? It seems the examples above show that the data knows the format

<nick1> Erik: ... we could make the media-type dynamic

<nick1> Charlie: We should use content-type to drive the encoding and media-type drives the UI

John: If we support to edit an XML subtree we need a Rebuild after every edit

<ebruchez> xf:copy: "as if an insert action had occurred"

because we are doing inserts and deletes

John: in case of copy we know what it always bind to a subtree
... In textarea the ref would sometimes bind to the text and sometimes to subtree

Erik: You can see the ref binding to a node, and the control deciding what to update because it knows if it is editing a subtree or a text node

<ebruchez> For reference, the Atom Syndication Format RFC: http://tools.ietf.org/html/rfc4287

Leigh: There is nothing different to the UI if we are editing an XML subtree or textnode

Charlie: I'm a bit scared of media-type driving how the data is represented in the instance.

Leigh: The xhtml has some deeper issues separate from the presentation
... I don't want to talk about xhtml, the problem is that we don't have anything to edit mixed content
... discussion about serialisation

Zakim: mute me

leigh: We want to bind to a subtree
... You could see to XML as something special, that isn't in the intsance, because the XML could be big simular to uplaod

wiecha: it could be shadow tree

ebruchez: we have a address component that edits the address subtree

<John_Boyer> ack [IPcaller]

nick: We have binds that go in the XML subtree to add additional constraints for example prevent bold

or limit the font sizes

<wiecha> Charlie: I'm just really confused about the idea of letting binds see the sub-structure of these complex mediatypes

nick: so the textarea binds to a subtree, but the rich text doesn't allows certain markup

<wiecha> Charlie: but maybe i shouldn't think about the element structure of the instance as being so different from the "data" of the app

nick: but I'm not sure if we want to support it by the spec

<John_Boyer> constraint="not(substring( whatever, '&lt;b&gt;'))"

John_Boyer: can't you do the same with escaped content

nick: are clients have xml and they want to add the xml subtrees easily

<wiecha> we're going to hit similar issues when we do components and let them manage subtrees

Leigh: We have to be careful that we don't allow malformed html that when rendered exploits are triggered by the javascript

John_Boyer: it is different in nick's case it is the author in leighs case it is the processors problem

Leigh: you can't use a regular expressions to protect it because it would be difficult to handle all edge cases, you need to use the real pipeline and then check it

John_Boyer: it doesn't seem to matter if the author or the processor and it both occures in HTML and XHTML

<John_Boyer> got dropped, redialing

Leigh: It is much easier in the DOM then it in the escaped string
... probably nearly impossible in the escaped string
... We could only insert the XML data when submitting like upload, but then we don't have the power of XForms constraints
... To choices are: outside the intsance, in a component, inside the instance,

ebruchez: gives example of an address component, and specialization to limit the valid addresses from the outside

wiecha: it is like an xhtml textarea a subtree coming back

Leigh: the separate tree could come back if we want to support hundred megabyte XML subtree

ebruchez: the xhtml case is a simple form of a component

John_Boyer: we also have the cross-implementation compatibility issues if we support the html rich content

ebruchez: we already have the problem today, because the components deliver different HTML if the run in FF and IE

John_Boyer: do we need to give access to serialization, but is that going to solve the compatibility

Leigh: I want to solve the cross site scripting
... We maybe need to support transformations when the data comes in and when it is submitted

John_Boyer: We have need transformations on simple content too, (gives example about number formatting)

wiecha: having a general solution for all controls would be great to have

(leigh gives a good summary )

Leigh: The control would be bound to a model that binds to another model by a sort of adaptor

ebruchez: not sure that a component binds using a ref, there is synchronization in both ways, there are updates to the component and the component can write data back

<John_Boyer> ref is not quite like submission because UI controls have lots of cases where the model projects data onto the UI without the UI initiating a "submission" to the model

<John_Boyer> This includes initialization and refresh

ebruchez: I don't really see the complete analogy with submit

wiecha: it is a bit like submission but there is more

ebruchez: we implement this with XBK, xf-enabled the data is fetched to the component, the component uses local data, and at certain times it commits its data back to the main document

wiecha: there is processing in common with submission but there are more things going on
... the component may update when the form is running not only when the control is initially showed

ebruchez: submission is really http centric, component communication doesn't needs the protocol stuff

John_Boyer: is mixed content low hanging fruit, or does it requires a lot of work

Leigh: There is a need for security which is hard with escaped content, but the mixed heavily changes our processing model

ebruchez: I don't know if it is that more difficult, if we only want to support xhtml mixed content we have the rebuild problem already with copy

John_Boyer: maybe we can only for now support a text area to bind to text content, but also to a subtree and only do the normal RRR and not the RRRR the author can add a value change listener that does the rebuild

ebruchez: the same problems happen with xf:copy

John_Boyer: if your code knows that it writes a subtree, just do the rebuild in your code

ebruchez: agrees

<klotz> http://json.org/module.html

John_Boyer: Some people want to sit in between the instance and the control to filter certain markup (script tags,...) but maybe we don't need to standardize that
... explains the cross implementation problem with using different rich text controls

nick: the problems also exists when you edit in a different browser

John_Boyer: explains problem with copy paste between MS Word and rich text area

<John_Boyer> if processor A has a better implementation of rich content than processor B, then the content is not interoperable across the two processors

ebruchez: there could be implementations in different languages not in Javascript on the browser
... it isn't possible to rule out all compatibility problems
... but I don't think that this should be a show stopper

John_Boyer: If we make it optional to implement, we could also add a note that states that there could be compatibility problem between implementations
... but the rendering/editing components just need to mature and otherwise HTML compatibility is just noted as being out of scope. XForms is just saying how to wire up these components which will hopefully be more compatible over time.

nick: I don't think we need to say something about interoperability because it is either a bug in the html that is generated or parsed by the component

leigh: I think it is out of scope of the XForms spec to specify something about html interoperability inside a text area component
... We don't say anything about the alpha transparency of PNG, which is a pain for IE6 users

<ebruchez> here

<John_Boyer> scribenick: klotz

<nick> +1 for mediatype

John: Should we pull off mediatype on textarea?

Charlie: I think we should open it up to the html case.

<ebruchez> +1

<nick> If no one volunteers I could put it on my list

John: Eric, since you provided one of the examples, did you implement the xhtml case?

Steven: What's the difference?

John: In XHTML we edit the data without encoding, using structural changes.

Steven: So it's XML.

Charlie: Inline
... A @ref has a subtree of XML under it instead of a string leaf element.

Steven: That sounds like the XHTML case.

John: Do we know of any implementations of the XHTML case.

Steven: So the chunk of XML that represents HTML is the case we're considering.

John: A text/html case that's encoded.

Steven: Just a string, in other case.

John: THen a separate case of handling XHTML as XML.

Leigh: My point about the text/html case is that it's purely presentation.

John: So are we comfortable not handling the XML case at this time?

Steven: Is it that much more work?

John: It changes the way the control behaves. We have no other control that does that.
... I'd like to see both.

Steven: Let's do both.

Leigh: It's our first real control that binds to a tree.

Erik: copy

Leigh: Copy isn't a control

Erik: But select does, with copy.

John: But it's a non-leaf element.
... Exactly

Leigh: So Erik why haven't you implemented it?

Erik: We had no demand for it. But there is no technical restriction.
... The minor processing model updates are there. We now have filtering on HTML.

John: So we already have a control that does tree manipulation.

Erik: The itemset does it, so it's the control

John: So it seems reasonable to do both. We can decide if we want it to go into FPWD.

Erik: Do we also support application/xhtml+xml encoded?
... And another mechanism to trigger the subtree addition?

<nick> an encoding attribute on textarea

Leigh: The atom people didn't do that, but they use keywords.

John: We could have encoding separately from MIME type.

Erik: Since it can store HTML as text why can't it store XHTML as text.
... It's not ridiculous to have encoded XHTML. Maybe namespaces.

<John_Boyer> mediatype="application/xhtml+xml; encode=true"

mediatype="application/xhtml+xml" transform="base64-encode"

Erik: I'm not sure anybody is in charge of certifying those parameters.

Leigh: If we're going to worry about this we should worry about the filtering.

John: So you think they are separable issues or not?

Leigh: If the default is to do & encoding and we then introduce application/xhtml then we'd need to introduce a way to say not to escape it.

Nick: Can't we default it based on mediatype and say you have to specify somethign extra if you want it the other way around?

John: I think Leigh is arguing that we want the default to be escaped.

Leigh: I think we can decide what we want but we have to discuss it first.

Charlie: We're confusing mediatype and contenttype.

Leigh: We have to decide what we want defaulted before we default.

John: Maybe type mip. I'm not sure how you'd do it for the empty starting case. Our type MIP only assigns simple content types.

Erik: Only datatypes.

John: It can't be a type MIP.
... Or you could drag in the whole XHTML schema.

Leigh: Or just div, as ATOM did.

Charlie: If it's encoded, it's a string.

John: If the field starts empty how can you tell it's supposed to be XML subtree?
... What do they say in atom for XHTML?

Leigh: in RNG, anything in the XHTML namespace.

Erik: ...
... A type MIP implies validation.

John: Or a different MIP.

Erik: I'd rather this be at the level of the control.

Leigh: It's data and it's a node; the only way we have of saying it's a tree is XML Schema.

John: It's a tree root, not a leaf node. I'd like to get to that on UI bindings as a qualifier.
... Simple content mutation or tree mutation, and that tells me whether to do a rebuild.

Erik: If the control updates the structure it should use insert and delete or some higher-level mechanism on the instance.

John: It can be a UI binding attribute to say whether it happens. the way the control interacts with the data is node replacement instead of content replacement.

Erik: That would be the only case.

John: We could have a tree control in the future.

Erik: It depends. The tree control might know.

John: We might have components in the future, custom controls that manipulate a whole tree.

Erik: An attribute specific to the controll.
... An xforms content type for xhtml.

John: Or any content, a subtree, that is generic.

<ebruchez> <xf:bind type="xforms:xhtml" ...>

<xf:bind type="xforms:svg" />

<John_Boyer> What about "any element"?

Erik: Do we have a generic case?

Leigh: Yes, drawing in SVG.

John: Isn't there an xsd:anyElement?

<Steven> that's what we use for instance content surely

<Steven> yes

It's complextype/sequence/xsd:any/@namespace="##any" but does that allow toplevel text?

Erik: We'd be looking at creating types. We could have a type for xhtml or a type for XHTML+XML.

<John_Boyer> actually looks like xs:any, not xsd:any

John: For any XML-based mediatype you would need an XML schema type.
... The type MIP doesnt' do type validation of complex types.
... So if we want a minimal exception.
... How do you operate without an XML schema then? Is there an alternative?

Erik: If you said xforms:xhtml it wouldn't mean a schema is required; the XForms engine could do it.

John: It could be any element.

Erik: with a built-in type you don't need a schema.

John: So if you had xforms:html as a new data type, how do we define it? They're not just keywords.

<John_Boyer> <bind ... type="xforms:any"/>

<ebruchez> unfortunately I have to switch to listen-only mode now

Leigh: If we use a schema-based way of indicating whether to encode or not, must processors examine all schema type declarations to see if they permit mixed content?

John: It seems heavyweight. Erik said maybe some aspect of the control defines whether it is XML encoded or not.

Leigh: Maybe we need a type mip that says it's a subtree.
... But we have that for select already.

<wiecha> really seems strange this should be set by the control

<wiecha> ...just judging from the IRC, sorry

<John_Boyer> true, though it is already set by the control in the select/copy case. Maybe, though, we don't want to further open that door

Leigh: We are taking Charlie's point that the encoding should be a data property, but it may be too hard to recover from a schema type declaration so perhaps we need a type MIP that says leafnode="true|false" or something.

<John_Boyer> everyone is also mulling a different kind of MIP than the type MIP

<wiecha> k, thx

<John_Boyer> Tried to do type MIP, but seems we would have to make an exception because type MIP does datatype (simple content) only

<wiecha> yup

John: not only leafnode="true|false" but also an xpath because it would be nice to associate leafness with the node based on some attribute of the node itself.
... Because that covers the atom case.

Leigh: Maybe we should be looking at schematron.

<nick> but then we should put it on the control again...

John: But it's our mip, not a type declaration.

Leigh: Wherever we put it is should be availbable in the instance.

<nick> could be dynamic not should I think

Leigh: it should be possible to be data driven.

John: So an xpath expression, on mip or control.

Leigh: Yes.

John: I'd like to get an action item on this. I recall Nick said he might be willing.
... Just make a choice; an xpath-bearing attribute to a control. Then after the first draft we can modify.

Leigh: That's better than a new MIP.

John: Yes, a leafness mip seems drastic.

<nick> just put it on my list then

<nick> if the group has a look at my e-mail of today ;)

<scribe> ACTION: Nick van den Bleeken to write up new binding on textarea for leafiness. [recorded in http://www.w3.org/2009/06/25-forms-minutes.html#action02]

<trackbot> Created ACTION-559 - Van den Bleeken to write up new binding on textarea for leafiness. [on Nick Van Den Bleeken - due 2009-07-02].

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/ te / the /
Succeeded: s/ase/case/
Succeeded: s/moed/mode/
Succeeded: s/moedl/model/
Succeeded: s/ly//
Succeeded: s/tion/tion?/
Succeeded: s/frms/forms/
Succeeded: s/forms/form/
Succeeded: s/model/component/
Succeeded: s/John: moving to more control around RRRR/Topic: More Control around RRRR/
Succeeded: s/so perhaps we should take up this RRRR/so perhaps we should drop this RRRR/
Succeeded: s/no, in favor of shooting it/yes, in favor of shooting it/
Succeeded: s/Topic: More Control around RRRR/John: moving to more control around RRRR/
Succeeded: s/comming/coming/
Succeeded: s/Hour 2: //
Succeeded: i/scribe: nick/scribenick: nick1
Succeeded: s/scribenick/ScribeNick/
Succeeded: s/need to mature/need to mature and otherwise HTML compatibility is just noted as being out of scope. XForms is just saying how to wire up these components which will hopefully be more compatible over time./
Succeeded: s/groups/group/
Found Scribe: Steven
Inferring ScribeNick: Steven
Found Scribe: Charlie
Found ScribeNick: wiecha
Found ScribeNick: nick1
Found Scribe: nick
Inferring ScribeNick: nick
Found ScribeNick: klotz
Scribes: Steven, Charlie, nick
ScribeNicks: Steven, wiecha, nick1, nick, klotz

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

Default Present: John_Boyer, wiecha, ebruchez, Leigh_Klotz, [IPcaller], Steven
Present: John_Boyer wiecha ebruchez Leigh_Klotz [IPcaller] Steven
Regrets: Uli
Agenda: http://www.w3.org/MarkUp/Forms/wiki/vFtF_2009_06_25
Got date from IRC log name: 25 Jun 2009
Guessing minutes URL: http://www.w3.org/2009/06/25-forms-minutes.html
People with action items: bleeken den nick van