Forms WG Face to Face Meeting 2 Nov 2009 -- 02 Nov 2009

<Steven> aha

<Steven> trackbot, start telecon

<trackbot> Meeting: Forms Working Group Teleconference

<trackbot> Date: 02 November 2009

<Steven> Meeting: Forms Face to Face @ TPAC, Santa Clara, CA, USA

<Steven> Scribe: Steven

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

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

Ongoing work

John: We want to produce a fpwd of XForms 1.2
... hopefully before the end of the year, in this charter period\
... thin spec

Leigh: We should brainstorm on how we want to do that

John: The problem last time was that there really was a lot to do, that we don't have to do now
... we need to limit the requirements

Erik: We need to brainstorm on new members

Steven: Call some names out

All: Cordys, EMC

Uli: The French guy

Steven: We could invite him, Alain Couthures?
... The British company, name escapes me at the moment

Erik: Mark and/or Paul

s/01name escapes me at the moment/Jadu

<wiecha> maybe the amplesdk guys

Steven: Yahoo as a company idea

John: Sun/Oracle for ODF

<klotz> http://gcn.com/Articles/2009/10/29/White-House-Drupal.aspx?Page=2 Obama supports RDFa

<unl> re starting an OASIS TC: "Any group of at least Minimum Membership shall be authorized to begin a TC by submitting to the OASIS TC Administrator the following items, written in English and provided in electronic form as plain text. No information other than these items may be included in the proposal." see http://www.oasis-open.org/committees/process-2008-06-19.php#formation

[Long unminuted discussion of chartering alternatives]

Uli: I prefer FtF to virtual meetings; they seem much more productive

<klotz> should I take over scribing?

<klotz> doesn't john need to type something?

<scribe> Scribe: Leigh

<klotz> ah I thought it had to be a channel op.

<scribe> scribenick: klotz

<Steven> nope

XForms 1.2

John: Let's discuss the possible candidates for XForms 1.2
... http://www.w3.org/MarkUp/Forms/wiki/CategoryXForms12
... Can we focus on the bigger, harder issues here?

Nick: I'd prefer to finish some of the ones that are almost done because we need to finish things to move forward.

Raman: How about components in XForms? That's a complex piece, like external models.

<Steven> http://www.w3.org/MarkUp/Forms/wiki/CategoryXForms12

John: That's a 2.0 issue.

Erik: We've done a but of work with components ourselves; it's amazing what you can do.

Raman: It's important to have a good component story, especially if XForms is an authoring environment.

Erik: We used components to expose YUI through the XForms data and event model; it makes applications easier.

John: Do your components have models?

Erik: Yes, encapsulated. Based on XBL. You can write a multi-model thing bound to data and events.
... And appearance.

Uli: That's 2.0.

Erik: Yes, it's a big piece. We started a year and a half ago. We've been amazed by the potential. It is like when Charlie did this years ago.

<wiecha> we're still interested!

Steven: It's important to pick up on the things our implementors are doing like JSON to the instance. If it's already been done, then maybe it's not 2.0. There's no research.
... Or maybe even not a 1.2?

Leigh: Or maybe publish a note or a submission.

Steven: Is it based on XBL 1 or 2?

Erik: XBL 2 but not compliant. We use foo:bar CSS selectors for binding. The hard part is with the XForms boundary crossing.
... You want SNB, value-changed dispatch, current context access, all from the component.

Steven: XBL is used often with XForms. Maybe we should consider making it a core technology.

Erik: Our impression was that XBL 2 didn't support id resolution, so we used XPath and ID resolution going through.

Raman: XBL2 doesn't have implementations.

Steven: XBL3?
... I would have thought XPath selectors were more suitable.

Erik: That's not the hard part. Even just static bindings are useful.

John: It seems important to publish something soon with low-hanging fruit.
... CaseFunction, @context

Leigh: Is the namespace changing?

John: No, the version number feature in the model.

Erik: We should be courageous and cut out things we can't quickly agree on.

John: Maybe components is 1.3 and some other feature is 1.4.

Leigh: I think the thin spec has worked well.

Raman: In practice, because of the complexity of software, big things never get implemented all at once.

Erik: So components might benefit from being a separate document. If you want to push a core spec forward, ok.

Raman: Do you need core XForms changes for components?

Erik: I don't think so.

Raman: So publish your components as a new thing.

John: Some of these things require core vocabulary changes.

Leigh: I think vocabulary is easy; behavior is harder

John: You have to chnage the schema

Leigh: Just add extension slots to the schema

Erik: To add variables you need to change the processing model: "Variables are evaluated during refresh." You then publish that as a diff.

John: We do need to get back to full specs, not thin specs.

Leigh: If you use a modularity framework you can publish the small documents.

<John_Boyer> for W3C

John: Can we discuss core or extension for each of these?

Erik: @context everywhere seems to be core.

Leigh: Adding it to SNB could be a module, but what about the behavior?

Nick: In a module

Erik: Right now it's in insert and delete. We could move it into SNB.

John: Why not an XForms 1.1 Generalized Context Module?

Nick: It's more work to create the modules.

John: We tried to modularize the whole spec, though.

Nick: We would need to have the Context spec say what it overrides.

John: Yes, but it's a set spec.

Nick: It's doable but...

John: How many are there?
... For context, my original reaction was it was hard, but there are only 4 spaces.

Leigh: It's essentially a very, very small thin spec.

Erik: It's doable

Raman: We talked about the exslt equivalent

John: Dialog is a beautiful module.

<Steven> we hear you

<Steven> I think the problem may be at our end

<Steven> we're going to lunch now

<wiecha> k

<Steven> l8r

<wiecha> bye

John: Nick, which topics did you want to cover?

Nick: XPath 2.0

Erik: Extension functions

Uli: 1.2 or 2.0?

http://www.mantrapaloalto.com/home.htm

Uli: optional model
... But maybe not a good module.

Leigh: If it works, ok.

John: I felt the same way but it's OK if it works I think.

Uli: What if they need to work together?

John: We need something more than hub and spokes; we can start from some and then rev the core.

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

John: We may have half a dozen examples before we run into that problem.

Uli: I'm not convinced.

Erik: Specific ideas? Submission simplification?
... Specific ideas? Submission simplification?

John: We'll change the language in modules. But we need velocity on new features and refactoring submission isn't it. Maybe components or dialogs.

<wiecha> how about patterns?

Uli: When do we prioritize?

<wiecha> could be low hanging fruit

John: That's the 1.2/2.0 list.
... Some are redesign. We decided to focus on easier deliverables to get FPWD out.

Erik: It's getting tight for that.

John: We can work on it.

Nick: We can just check them off when we write the document and titles.

Charlie: The pattern work as well; master/detail, repeat, wiznav.

Leigh: That may turn into components.

Charlie: I wouldn't tie to components.

John: I thought it was new markup and new processing; not as low hanging.

Leigh: How about publishing modules for dialog and components

John: As FPWD?

Leigh: As modules FPWD for XForms 1.2

John: We need a shortname.

Leigh: xmlschema has xmlschema-2, xmlschema11-2 etc.

John: OK. So technically these could be specs.

Leigh: Pick dialog and then another one that's already implemented, say components.

John: Or extension functions.

XPath 2.0 Support

Nick: XPath 2.0 support.

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

* XPath 2.0 support

Nick: We add XPath 2.0 support but keep 1.0 support.
... You can put it on the model.
... Supports xpath 1.0 compat mode.

John: Maybe we need versions for modules.

Uli: We need to move XPath to a module.

John: We have a module already.

Nick: We're not going to modularize the whole spec.

John: Submission says module, but XPath doesn't.

Uli: I think it would be hard to grasp for readers.

John: Chapter 7 is the module; it just doesn't say "The XPath Expressions Module."
... We can republish it as 2.0.

Leigh: So what breaks if just publish http://www.w3.org/MarkUp/Forms/wiki/XPath_2.0 as xforms12-xpath2 FPWD? What breaks in the rest of xforms11 and how do we publish those changes?

Nick: I have a table of function changes, mostly parameter types.

Erik: 8.11 has a note. There are going to be more.

Nick: Also supporting sequences. There may be more changes needed throughout the spec.

John: Are you still assuming that in an xf:bind that the result of the expression is a nodeset?

Nick: A sequence of nodes and not a set of nodes is how I now interpret it. Not in document order.

Erik: A nodeset will have exactly one node once. In XPath 2.0 you can have a sequence with repeated nodes.

Nick: They are always in document order in XPath 1.0.

Leigh: Even in a union?

Nick: Yes. They are interleaved.

Erik: Except for attributes (for which order is not preserved) in Xpath 1.0, ...

Nick: In a union you can combine nodesets in document order.

http://www.xml.com/lpt/a/940 says XPath 1.0 nodesets are unordered; XSLT ordered them.

Erik: I can use a sequence that iterates over 4 items, two of which are the same node. So you can repeat over 4 items, 2 of which are the same.
... We need to decide for MIPs.

John: There is language which says that the xforms-rebuild the first step is to evaluate the nodeset and select an xpath nodeset. This is outside of chapter 7. We could specify a processing rule for handling sequences.

Erik: The only issue we have found is bind. We can't have two bindings of the same.

Uli: You can but you just get an exception.

Leigh: OK, so just don't do that?

Erik: Charlie made an argument about validity.

Leigh: So we add the "multi-node binding rule."

John: Yes, that's what I'm asking. We boil it down to a nodeset.

Leigh: bind/@nodeset would use the MNBR but repeat/@nodeset wouldn't.

Uli: How is a nodeset defined?

Erik: ...

Nick: A sequence of node*.
... We also need to look at attribute naming. Maybe it should not be 'nodeset'
... Maybe we just say you can't have the node in twice.

John: This is an answer to the question of why we can't just republish chapter 7.

Leigh: If we have an answer to these questions we can publish that as chapter 1 of the FPWD and then chapter 2 is "replace ch7 with this."

John: A bind with a sequence of nodes and no MIPs could be a binding site for a repeat.

Erik: So binding exception does a good job.

Nick: I restructured evaluation context using the XPath 2 ideas. It's clearer now.
... It is bulleted, and shows static and dynamic context.
... Variables are out of scope for this document.

John: "signature" isn't used in XPath 1.0.

Nick: It's an XPath 2.0 term but if you put them side-by-side you can match the concepts.
... You have to define the static and dynamic context properties to integrate XPath 2.0 and I have defined them here as bullet items.

John: How does the model ask for the xpath version?

Nick: I added a model/@xpath-version.

John: That's back to the module version issue.

Nick: It specifies the xpath version, not the module version.

John: so model/@xpath-version="1" means XPath 1.0 compat mode?

Erik: Which does not work perfectly.

John: But is elsewhere specified.

Leigh: According to http://www.xml.com/lpt/a/940 XPath 1.0 nodesets are unordered; only XSLT defines an order.

Nick: Right, I forgot.

Erik: What do we say?

John: In 3.3.1 we talk about schemas.

Nick: The in-scope schema definitions are from ch5.

John: And the ones from the model, in ch3.

Erik: We don't use the schema-aware version of Saxon.

Nick: you can cast them

Erik: For a simpleType such as my:zipcode, we don't expose that to XPath expressions.

Nick: You can use isCastableAs

Erik: We may need a distinction between SA and non-SA versions.
... The built-in simple types are easy to implement. But if you have full type support it's harder.

John: Here it's limited to ch5 definitions. So why can't we add form-defined ones? If we allow that, then the question is should we use the xforms type mip?

Erik: We do that as an option.
... That causes some problems though, which is why it is an option for us. You'd like to use xpath expressions in if.
... But an XPath engine running on a node, the value might not be true or false.
... We return an untyped value if it's not in the value space, else a typed value.

John: And you can dynamically decide the datatype of name test?

Erik: Yes, it's a strongly typed object (boolean, integer, custom) . Dynamically you can ask and check.

Nick: if the function was expecting a boolean it will fail, or will convert to a boolean.

John: If we had a node called hasInsurancePolicy and do bind/@type to boolean and also use a relevance calculation that collects the policy info...
... ... how do we write that relevance rule?

Erik: That's what we do.
... relevant="../hasInsurancePolicy"
... If it doesn't have a type it will always be true as it's an existence test.

John: Unfortunately, that leads to a major problem.
... If the XForms type MIP info can be fed into expression evaluations, we can create dependencies on the order of evaluation of binds.

Erik: Yes, good point. We run type assignments before running calculates in order to avoid that problem.

John: It's not been a problem so far because of static types.

Erik: We have xsi:type but it's static.

Leigh: it's not static.

Erik: Oh, calculate. I doubt anyone implements it.
... When the variable is evaluated, if the type is mismatched it will get a dynamic exception. So the exception cannot access a node of expected type. In XForms we can do assignments ahead of time and it's not an error for a node to be invaliud.

John: We don't describe xsi:type processing.
... That's why we don't have MIP access functions, to avoid the dependencies.

Erik: If you use valid() inside relevant() it will not be up to date.
... You run into tricks. The declarative magic ought to work.

John: It's on the 2.0 list to consoldate recalc and revalidate

Erik: it's very convenient to use the type info in xpath 2.0.
... You get the simple types. If you don't have them then you'll use cast all the types.

John: We need to support the schema types for our customers because many rely solely on schemas for validation.

Erik: That could be static.

John: it's not just types, it's type assignments.
... my:phoneNumber is one thing but the xsd:boolean is necessary.

Nick: I never wrote down that nodes get type information. It isn't part of the evaluation context.

John: does xpath 2.0 let you give types to nodes?

Erik: It's part of the data model.

John: So we don't say what the data model consists of.

Nick: I need to add that.

John: So where do we allow nodes to get their types from?

Nick: is it a problem to get the types from schema or xsi:type
... for simpleTypes ok but i don't know for custom types.

John: Sounds like an editorial node for FPWD.

Nick: It says we require at least Unicode codepoint collation.
... We don't say what the document function does.
... And standard collections.

John: What is a document in xpath 2.0?

Erik: A document node.

John: Can you use "."?

Leigh: In XSLT document() gets you the XSLT document.

John: So do you get the host document or the instance?

Erik: It would be the stylesheet, or the host document, but I'm not sure you'd mandate it.

John: Steven you talked about applying calculation to the document.

Erik: You could say that document("") could return the host document, but it would be a big burden.

Nick: You'd need the live instances.

Erik: Not necessarily.

John: "When a constraint is blown" "I want to turn the text red."

Erik: We use AVTs. class="foo-{xpath}"

John: They want to put the bindings together as a collection.

valid, color.

Leigh: Sounds like a mixing of levels.

John: Steven wanted to be able to modify the host document.

Steven: Sebastian was close to doing that in his implementation.

John: So I would move information out into presentation layer.
... It's a declarative version of class.

Leigh: It seems like a good use case but even the AJAX people hide the DOM modification from you as much as possible.

Nick: It's hard to know when to send over changes in a server side system.

Leigh: Erik's AVT sounds attractive because you then know where the flex points are.

Nick: The functions library.
... Functions will be in the xf: namespace.
... That should say xpath2 only.

John: We also said we'd make them available under the namespace to xpath 1.0 processors.
... We need to sort out the may/should/must here.
... the unqualified names should still work in xpath 1.0 though.
... Can you change the element namespace default?

Nick: You can in xslt.

Leigh: Can we add it?

Nick: it is per element and inherits.

Erik: Default namespaces are evil. I use them all the time. Last time I used them I had a bug.

Nick: It's useful in the saxon evaluate function.

Erik: Would it be scoped lexically or by model?

Nick: Do we add it?

Leigh: We should add it but put in a note.
... Why not just publish this as xforms12-xpath2 and not mention xpath1 in it at all. Either implement it or don't.

John: But we have to thick spec it at some point.

<unl> *is increasingly unkindly requesting a combined bio and coffee break*

Leigh: maybe.

Nick: I dont' want to have to take the xpath 1.0 out of this.

John: We need to re-write it anyway.

Leigh: Yes, just publish the xpath 2 only as fpwd.

<ebruchez> scribe: ebruchez

<scribe> scribe: Erik

<scribe> scribenick: ebruchez

Nick: (will work on specxml for XPath 2.0 support)

John: With XPath 2.0, should we put avg(), etc. in a namespace.

Erik: So is the plan to put all XForms functions in a namespace? Or just the ones that conflict with XPath 2.0?

Nick: Yes, plan is put all of them in ns, but implementors can additionally decide to put them in null ns for backward compatibility purposes.
... (discussion dateTime conversion)

John: We say that default type for nodes is string

Nick: dateTime can be converted from a string

Leigh: if we populate instances with datatypes, we will have issues with empty values?

Erik: (explaining what XPath 2.0 expects when dealing with nodes' typed values)

Leigh: XForms has mutable data, which is a difficulty compared with XSLT 2.0.

We might consider switching default type from string to untypedAtomic.

http://www.w3.org/TR/xpath-functions/#casting

Erik: string and untypedAtomic mostly behave the same as far as casting is concerned

Nick: I used item()* in the choose() function.
... Open question about sequences. But w/ xf:repeat, then it would be good to support a sequence of items.

Erik: Might be some consequences, e.g. items="(1 to 10)"

John: What would be the point of a group bound to number?

Erik: Not saying you should bind a group to a number, probably not much meaning.

John: (XPath 2.0 questions)

Nick and John: (discussing implications of bind resolution within xf:repeat/@items.

Nick: You can't bind a MIP to an atomic type.

John: Or, since you can't use the value, just ignore the MIP.

<John_Boyer> mainly, shouldn't do bind element on items, only nodesets, so bind attr on UI element will still refer to nodesets

Erik: Are we thinking about calling a new attribute @items?

John: Not necessarily, might pick different name.

Erik: Concerned about the number of attributes.

John: We already have "items" in XForms, so not such a good name.

<John_Boyer> but we also have a select

<John_Boyer> already too

Erik: Can't use @value for xf:repeat.

Leigh: Could you use xf:input/@select?

John: No, single-node binding would still be @ref.
... E.g. <group select="..."><input ref="...">: what would that get us? Not very useful.

Leigh: Could we define @ref to mean @select + MIPs + events + ...
... Would xf:setvalue/@value convert to a string?

Erik: Are we accepting dups on xf:repeat/@nodeset?

Nick: Yes. With xf:bind/@nodeset, you get a binding exception.

<John_Boyer> but with xf:repeat/@nodeset the repeat would just iterate over the xpath 2.0 items in the order given.

<klotz> xqueseme: Mozilla XQuery extension using Saxon: https://developer.mozilla.org/en/XQuery

<John_Boyer> ACTION: Nick to create spec XML for "XForms 1.2: XPath 2.0 Support Module" based on XF 1.1 ch. 7 + wiki content + today's discussion [recorded in http://www.w3.org/2009/11/02-forms-minutes.html#action01]

<trackbot> Created ACTION-576 - Create spec XML for "XForms 1.2: XPath 2.0 Support Module" based on XF 1.1 ch. 7 + wiki content + today's discussion [on Nick Van Den Bleeken - due 2009-11-10].

- DRAFT -

Forms WG Face to Face Meeting 2 Nov 2009

02 Nov 2009

Attendees

Contents

Ongoing work

XForms 1.2

XPath 2.0 Support

Summary of Action Items

Scribe.perl diagnostic output