*DRAFT* W3 Forms F2F (Hawthorne) Day 2 June 14, 2007

* Present

Steven Pemberton, CWI/W3C
John Boyer, IBM (chair)
Charlie Wiecha, IBM
Uli Lissé, DreamLabs
Leigh Klotz, Xerox (minutes)
Keith Wells, IBM
Nick van den Bleeken, Inventive Designers
Roger Perez, SATEC
Mark Birbeck, x-port.net (remote)

* Agenda


* Day 1 Minutes


* IRC Minutes


* Schema is gone in latest editor's draft

John Boyer: Martin's comments refer to Appendix E, but the draft has Appendix D.
Steven Pemberton: Schema Appendix A is gone

Action 2007-06-14.1: John Boyer to fix missing Schema Appendix A in latest editor's draft of XForms 1.1

* 1.0 errata section 10 (complex type validation clarification)


John Boyer: Steve Spreicher is satisfied that XForms is not trying to give special meaning to xsi:type, but "perhaps this can be clarified in 1.1 Drafts."
Leigh Klotz: Let's look for xsi:type
John Boyer: Here it is in 6.2.1
Leigh Klotz: Yes, bullet point 2 "An XML Schema xsi:type attribute in the instance data." makes it look like the XForms processor does this, when in reality it's the Schema processor, so the effect is defined in XML Schema.
John Boyer: So we copy the language from 4.3.5 instead, maybe say Schema information?
Leigh Klotz: Yes, it's type info from the Schema processor instead of type info from a Schema followed by type info from xsi:type.
Leigh Klotz: Also in http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-all.html#fn-id it says that xsi:type can be used to assign type ID to an attribute, which it clearly cannot; xsi:type can only assign types to elements.
John Boyer: Let's treat that as a separate issue; there was a lot of discussion from David and Kenneth on the id function and this issue is about complex types. You can file that as a last-call comment.

Action 2007-06-14.2: Leigh Klotz to file last-call comment on id function and xsi:type

John Boyer: The bullet point will remain as empty; before CR I have to remove it.

Action 2007-06-14.3: John Boyer to manually remove empty bullet point in model-using-atomic before CR.

John Boyer: OK, on the rest of the points. [reads]
Leigh Klotz: Yes, we agree on the xsi:type restriction point.
John Boyer: What about xsi:schemaLocation. Are these two equivalent?
Leigh Klotz: No.
John Boyer: We say in section 6.2 that we don't use xsi:schemaLocation.
Leigh Klotz: In the Schema for XForms we say not to process Schema for inline instances when reading the document.
John Boyer: What about external instances?
Leigh Klotz: We don't say.
John Boyer: We do in 6.2. "Attributes xsi:schemaLocation and xsi:noNamespaceSchemaLocation are ignored for purposes of locating a Schema."
Leigh Klotz: So you can't use xsi:type in instances if the source of the type library is xsi:schemaLocation.
John Boyer: So the two are not the same. But how do we tell the Schema processor to ignore it? Uli said it wasn't possible a minute ago.
Uli Lissé: Sorry?
John Boyer: I think you can tell it not to use the Schema location when you run the Schema processor, and we claim that is is possible, and I thought you said we don't have any control over that. Maybe not in all processors, but we may in a number of them.
Nick van den Bleeken: XML Schema says it's a hint. http://www.w3.org/TR/xmlschema11-1/#xsi_schemaLocation
Leigh Klotz: So in case 2 in the message, we still ignore the xsi:schemaLocation and so if the instance has xsi:type then the form author must explicitly list the Schema, and this is no change.
Keith Wells: The Schema Appendix A got moved to E.
John Boyer: Thank you. I remember now. There is a set of normative appendices and a series of informative appendices and the Schema is not normative.

Resolution 2007-06-14.1: http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Types?id=135 On point 1, we made the change to section 6.2.1. So on point 2 we decided it was already in agreement; on point 3, the same instance data outside of an XForms processor might have xsi:schemaLocation processing on, but it is indeed off in XForms.

* The Insert Event

John: Erik wants what happens when the optional attributes on insert are not specified.  In the case where insert contains neither nodeset nor bind (using the context attribute and inserting into children), the xforms-insert event binding is the empty string.  I'll dig one of these up.  None of our examples have this yet.  Eric is supposedly working on it. 
<insert context="instance(<code>people</code>)" origin="instance('peopleProto)" ev:event="DOMActivate" />

John Boyer: So if bind and nodeset are both missing, the binding property returns the empty string.
Leigh Klotz: Can you get the context?
John Boyer: Technically the context isn't the binding.
Charlie Wiecha: It clearly says that it's the value of the attribute.
Leigh Klotz: It's clear but it's useless.
John Boyer: It's for the form author to detect the insert's he's created.
Leigh Klotz: If that's the case then there should be a way to get the id of the insert itself.
John Boyer: As long as you put an id. But it's to see which subtree of data. Three triggers may invoke an insert; if they express the XPath the same way (or easier using bind) you can tell.
Leigh Klotz: It looks semi-useless to me; it doesn't tell you whether it's a nodeset or a bind, or what the context is.
John Boyer: As a spec writer, it would be nice to re-express the behavior of repeats in terms of listeners for these events. Right now we say that the inserts themselves somehow alter the repeat indices.
Leigh Klotz: PicoForms would be perturbed by using events there.
John Boyer: You don't have to do it that way; we just specify it that way. Repeat should be detecting chnages of the data and manipulating its index accordingly. I talked to Raman about this a couple of years ago. He said the repeat index language in insert is mean to imply that the index adjustments would occur as a side-effect of insert but not necessarily as direct programming or implementation of the insert. I agree with that point, but most people reading the spec who are implementors see the language in the insert action and they assume it has to be a property of the insert action. I guess that's what we want to get away from. Increasingly we're using insert as a generic DOM manipulator and there may no repeats that are bound to exactly the same nodeset as the insert binds to. This is a real problem for insert now; you can insert a child node into an element via the context, and if the repeat binds to the children of that same node, there's no way to express how to manipulate the indices based on the nodeset the insert binds to because it's something different that what the repeat binds to. Right now, I guess I'd say that the insert language is technically broken because there are lots of ways to insert and the repeat indices won't get updated. I'm not sure how much we should go on about this.
Leigh Klotz: Back to the xforms-insert binding property.
John Boyer: It's fairly useful. There are limitations where we could use another property.
Leigh Klotz: I don't understand why there isn't the correct fix isn't to have nodeset, bind, and context (context returning the actual context).
John Boyer: So we could assign Erik the task of doing that?
Leigh Klotz: I'd like to give Erik latitude to fix it if he wants.
Uli Lissé: Or remove it.
John Boyer: Yes, we could just remove that property.
Leigh Klotz: This seems underspecified. I don't understand the usecase.
John Boyer: I'd like to understand which homogeneous collection is being manipulated.
Leigh Klotz: You're using it as an opaque datum, not an XPath expression (which it isn't).
John Boyer: Yes.
Leigh Klotz: So I think we should send fix the narrow issue and then send this back to Erik for clarification saying that the whole feature seems underspecified and the use case is not clear.
John Boyer: OK. And the same for delete?
Leigh Klotz: Yes, good point.

Resolution 2007-06-14.2: On http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Events?id=108 We accept Erik Bruchez's request to clarify that the empty string is returned by insert event binding if none is specified. We also ask for clarification on the feature and its use case, because in general, it is not possible for the form author to resolve the value without knowing the context and without knowing whether the binding is a bind IDREF or an XPath expression.

Uli Lissé: And it's in delete as well.
John Boyer: I did it in 4.4.5 and 4.4.6.
Uli Lissé: Erik says he suggests getting rid of it anyway unless there is a use case.
John Boyer: I have a use case. I have a model and two subtrees in instance x and an instance y. For some reason known only to me, I want to keep some parallel thing going on in some instance. I only want to do the parallel thing based on mutations of the second subtree, not the first. In XForms 1.0 for every insert in the DOM you get the xforms-insert event but you can't tell what you inserted into. If out here I want to create some kind of action that does xforms-insert if binding is equal to some value xyz. If I have a nodeset "abc" that indicates the first subtree and "xyz".
Steven Pemberton: That suggests that if neither attribute is specified you want the context.
John Boyer: That's what Leigh said.
Leigh Klotz: Either bind/nodeset/context or just an opaque datum, depending on the use case. John's use case is the opaque datum. There is no use case for bind/nodeset/context yet.
John Boyer: Can I use the context to check against in my xpath expression? All of the operators redefine comparisons between nodesets between comarpsion
Uli Lissé: YOu can do the id function.
John Boyer: It doesn't have an id.
Leigh Klotz: The other function that does memory equality.
John Boyer: generate-id.
Leigh Klotz: Is there a way to find the nodeset by which the position is used?
Uli Lissé: insert-location-node.
Leigh Klotz: What if we just had the inserted location nodeset and you could satisfy your comparison use case with generate-id equality testing.
John Boyer: Why do we need any of this, designing it this late?
Leigh Klotz: Let's throw it out.
John Boyer: It would be convenient.
Leigh Klotz: Nobody has implemented it or knows.
John Boyer: They will in CR.
Leigh Klotz: Let's just move on. It's not that important.

* Action 105


John Boyer: I agree that the things pointed out are true, but I don't agree; every time a data model for the document is created you cannot guarantee that the attributes are in the same order. The XPath data model lets you use positioning on the attribute axis, at your own peril.
Charlie Wiecha: Aaron raised this as well.
John Boyer: It isn't true that you can't say where to insert.
Leigh Klotz: How do you say to insert it using XPath?
Nick van den Bleeken: Does the order stay the same?
John Boyer: The order doesn't stay the same across XPath invocations.
Leigh Klotz: What spec to we reach into for language about inserting, since XPath doesn't do insert. It's an immutable data model.
Charlie Wiecha: There's no update.
John Boyer: We define the update.
Mark Birbeck: I can't quite hear.
John Boyer: I was just saying there is nothing illegal about claiming you are trying to insert an attribute a particular location and that it doesn't mean that it's going to be inserted at that location; it just means it's going to be inserted in the attribute axis. Someone may say not only insert the attribute, but also if someone puts in the additional attributes on the insert action at position=4, I believe they can attempt to do that and nothing should crash. The very next XPath that they attempt to evaluate may find that it isn't there.
Steven Pemberton: So you're saying you can say please put it here, but it doesn't necessarily go there.
John Boyer: Yes
Steven Pemberton: So why not just say that?
Mark Birbeck: The bit Paul is referring to here is the "target location" which is differnt from what you're saying which is that an author might say at="*[5]".
John Boyer: It's the same issue.
Mark Birbeck: In know it's the same issue, but we're talking about the wording.
John Boyer: So we can tweak the wording and say that in attributes, the axis is unordered.
Charlie Wiecha: I think that would make Aaron happy too.
Mark Birbeck: My recollection in talking to Paul is that the XPath data model says that the attributes are ordered but that the order is implementation dependent, so if you insert at position 4 you should get it back at 4. That's not a problem. The problem is that it's insisting that we write at position 1 and there's no way to guarantee ithat.
John Boyer: XPath supports a single nodeset query and it doesn't support a query followed by a DOM mutation followed by another query; we can't say that the XPath spec guarantees the attribute order across the mutation, because some XPath data models are based on hashtables. So there's no way to guarantee that you put one first.
Leigh Klotz: Where's the problematic language?
John Boyer: Bullet point 6 doesn't say anything about the insertion.
Leigh Klotz: The comment says 6a and 6b. Should we just strike that sentence?
John Boyer: We have to do a little more, in point 7 it mentions the target location.
Leigh Klotz: What is the datatype of "target location."
John Boyer: It doesn't have one.
Leigh Klotz: So we can say "If the cloned node is an attribute, "...
John Boyer: "then the target location is the the attribute list of the insert location node."
Leigh Klotz: Is the insert location always an element?
John Boyer: No. The context must always be an element but the nodeset can be an attribute.
Leigh Klotz: So if the insert location node is an attribute, then insert location is the attribute list of the insert location node's parent element. Is parent element the right phrase here?
John Boyer: Yes. The specxml from Eric has a "TODO" comment about fixing this!
Leigh Klotz: We should tell Eric about the issue element.

Resolution 2007-06-14.3: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Action?id=105 we change 6a and 6b to say that the insert location is the attribute list of the insert location node's parent element.

* Break

Leigh Klotz: Is at optional?
John Boyer: Yes.
Leigh Klotz: What does it say
John Boyer: "Optional attribute..."This attribute is ignored if the Node Set binding is not specified or specifies an empty node-set."
Leigh Klotz: Could we add "or specifies an attribute".
John Boyer: Then we'll have to change point 4. But it's not necessary because it just narrows it down to a particular attribute whose parent we then use.
John Boyer: Do we have a problem with delete? Unless someone complains it is ok. We should be able to delete node we have a hold of.
Leigh Klotz: I agree.

* Document Versioning


Steven Pemberton: Personally I think this is better than what we currently have which is putting it on the model.
John Boyer: Yes, it says any element now. We'd have to fish it out of the host language elements. What happens with conflict?
Leigh Klotz: So this joins the repeat attributes as being an attribute in a foreign element.
John Boyer: Can you restrict foreign namespaced attributes on elements using XML Schema?
Leigh Klotz: Yes, in fact you have to allow them.
Steven Pemberton: If there were a Schema for this document type, then it would include the xf:version attribute.
John Boyer: I'd like to be able to grab all the XForms elements at once.
Leigh Klotz: You already have the model and the UI scattered.
Keith Wells: You have that problem with the repeat elements already.

Steven Pemberton: It's nice to have it on the root element.
John Boyer: What if someone puts it on the body instead? Does it apply to stuff in the head?
Leigh Klotz: I kind of have a preference for not requring it on the root element because it makes it hard to include XForms without altering the document. I don't have an opinion (yet) on allowing it.
Steven Pemberton: I see.
John Boyer: [reads] We already have a way to do this, on the model.
Leigh Klotz: I think that there needs to be an allowance for an XForms processor integration to specify the level.
John Boyer: The root atttribute does that. The model attribute is a request from the form author.
Leigh Klotz: I think that legacy implementations will support no attribute meaning 1.0 but future implementations are likely to start at 1.1 or 1.2 and not bother implementing then-deprecated 1.0 semantics.
John Boyer: Our processor doesn't use the 1.1 declaration but our host language has strong versioning.
Charlie Wiecha: The model attribute doesn't help the UI elements.
John Boyer: The UI is instantiated from the model.
Leigh Klotz: This is supposed to reduce the flurry of emails by being easier to find but I don't think the top of the HTML file is a good place to put it. And if you run this through a 1.0 processor it won't tell you anyway. Why don't we ask Mark to write an example using the suggestion from Keith to read the version property and pop up a message.
Steven Pemberton: The mistake is that 1.0 doesn't have this and won't object. In the future they should object.
Leigh Klotz: We have that on the model.
Steven Pemberton: The root attribute is more widely accessible.

Steven Pemberton: What about lazy authoring where there is no model?
Leigh Klotz: It requires a model for the model-construct-done and ui init events.

John Boyer: We have xforms-version-exception to the default model if the version on the model doesn't match.
Leigh Klotz: I don't have any objection to allowing it. I object to making it the only way.
John Boyer: I object to that too. So we have to keep the version attribute on the model. As currently specified, it doesn't leave an opening. Then we break backwards compatibility.
Leigh Klotz: ...two issues, XForms 1.0 errata to look at this and XForms 1.1 going forward.
John Boyer: What about xf:output with mediatype that includes XForms models.
Leigh Klotz: Version confict with xf:output mediatype is the least of the problems with recursive composition inside xf:output.
John Boyer: This is a new feature.
Leigh Klotz: It's a feature change.
Charlie Wiecha: It's fairly late for a feature.
John Boyer: Let's wait for Mark.

* Error information

Steven Pemberton: It should have a hyphen and be error-information.

Resolution 2007-06-14.4: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Events?id=96 we change to error-information with hyphen.

* Document Versioning


Keith Wells: Let's read the other comments on this.
John Boyer: Joern strongly disagrees with allowing xf:version on any element. I agree.
Leigh Klotz: He brings up the dynamic documents issue, and also says that it's a pity that XForms 1.0 didn't do it.
John Boyer: We can add it to XForms 1.0 Third Edition but we have to add the exception.
Leigh Klotz: Or just say "processing stops" because it's not handleable.
Steven Pemberton: It's not either/or, it's one or both.
Leigh Klotz: I think it's model or both. There are too many objections to requiring it on the root element.
John Boyer: Then what does it do?
Keith Wells: If model always wins, what's the point?
John Boyer: Then what's the point?
Leigh Klotz: Ask Steven.
Steven Pemberton: I thought this proposal was for anywhere, not just root element. If we had fixed it in 1.0 then it wouldn't be a problem to try to tell 1.0 processors.
Leigh Klotz: Does it matter whether 1.0 has the root element or model element in 1.0?
Steven Pemberton: No, it doesn't.
John Boyer: So I suggest we put this in the future features list and leave model in for now.
Keith Wells: I agree, we should defer this.
Steven Pemberton: This is just like missing it for 1.0; it gives us another legacy version we can't fix.
John Boyer: Part of the problem is assuming we can fix it in the future.
Charlie Wiecha: It's not suggesting taking it off the model.
Keith Wells: A future requirement.
John Boyer: Later when we aren't doing last-call issues.
Steven Pemberton: If Mark is just suggesting this as documentation then I don't think it has any value add, really.
John Boyer: Yes. To avoid email there's something you can do to the form instead.

John Boyer: The proposed resolution (waiting for Mark) is that we defer this as an issue for further discussion after 1.1.
Leigh Klotz: Something like this instead:

<xf:message ev:event="model-construct-done" if="property('version') lt 1.1">
  This document requires XForms 1.1.

Mark Birbeck: [joins]
John Boyer: Would you be willing to accept that resolution?
Mark Birbeck: I'm reading the minutes now.

* XPath 2.0 features

John Boyer: We're not based on XPath 2.0 so this is a future features issue and isn't a 1.1 requirement.
Leigh Klotz: Yes, XForms 1.2.

Resolution 2007-06-14.5: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=107 XPath 2.0 features, though valuable, are not in scope of the XForms 1.1 requirements, so we accept this as for XForms 1.2 future features.

* Document Versioning

Mark Birbeck: This isn't a new feature; I was asked to submit this not as a new feature but because the version attribute on model doesn't work. It doesn't really achieve what we want it to achieve. If you have a form that is compatible with XForms 1.0 and XForms 1.1 it will get rejected if you put XForms 1.1 on there. We had a discussion where we said we shouldn't be so draconian and give some indication to the readers of the document but the processor shouldn't be so draconian.
John Boyer: So backing up a step, the use case you identified in the issue is covered by the markup we provided. The other issue you are raising, that the version attribute in XForms doesn't do what we want it do to, can you go over that again? I don't think that's correct. I think you said if you designed a form to work in a 1.1 and a 1.0 processor it would be rejected by a 1.0 processor. Why? Just leave the version attribute off.
Mark Birbeck: How do you know that that's how you designed your form? Authors who are going to cut and paste. If you take a form that is 1.1 but doesn't use any 1.1 features, why should it be rejected?
John Boyer: We have separately talked about adding to an erratum for 1.0 support for the version attribute.
Leigh Klotz: If we did that then would we have version=1.0, version=1.1, and version missing meaning processor's choice?
John Boyer: I don't think so. The author should know.
Mark Birbeck: Suppose a hard-coded RSS feed submission; the author should remove that.
John Boyer: They're really smart to write the example.
Mark Birbeck: I wrote the example.
John Boyer: So they modify your example?
Mark Birbeck: It seems to me you need to be too aware of the where the feature comes from. If I remove the resource element and replace it with action=x then I need tobe aware of that.
John Boyer: That's the reverse case right?
Mark Birbeck: The document would be rejected by 1.0 but there's no reason it should be.
John Boyer: You're talking about downgrading.
Leigh Klotz: Can't we just have version=1.0 as an erratum, and version=1.1 for XForms 1.1, but if left off, leave it as unspecified, and say authors "should" put it on.
Mark Birbeck: If you find any element that isn't in 1.0 then you must reject the form. Then if xf:resource pops up it should be an error.
John Boyer: There are features of XForms 1.1 vs. 1.0 that behave differently.
Leigh Klotz: Why can't we leave it missing as unspecified?
Mark Birbeck: There are a number of implementors who aren't going to implement 1.1?
Leigh Klotz: Almost every significant implementation has already implemented 1.1 features in 1.0 anyway. I argue for version=1.0 and version=1.1 being strict and no version being loose.
John Boyer: If the form really depends on the features then an actual message action would be necessary. I think that construct would get used more than the attribute itself.
Mark Birbeck: Possibly.
Leigh Klotz: I agree with Mark's point that people who say version=1.1 might not know what they're doing.
John Boyer: I like the proposal that missing version is whatever version.
Mark Birbeck: Or maybe we can retrofit cherry-picked versions into 1.0. [leaves]
John Boyer: I think the version attriute has been shot down before.

* Lunch

John Boyer: Mark's message says something not enforced, which we can read according to what he said on the phone as "less draconian." So if we can enforce a version-conformant processor only when the version-conformant processor is specified, and if the version is not specified, it's up to the implementation to do its best job with the markup.
Leigh Klotz: What does an XSLT 1 processor do when XSLT version=2? Is there a compatibility mode?
Nick van den Bleeken: You can run XSLT1 in XSLT2 compatibility mode with version=1.
Leigh Klotz: We can do that too.
John Boyer: XForm isn't a host language though. There's XHTML as a host language which is less strict and web-do-your-best-job. There are other more strict host languages such as the one I have. I'm sure there are other types, but the versioning requirements come from expectations about that host language.
Leigh Klotz: So you should be able to let your host language integration specify the conformance level.
John Boyer: We do it in ours on a feature-by-feature basis.
Leigh Klotz: Interestingly we removed the XForms 1.0 normative reference so there's no way for an XForms 1.1 implementation to implement XForms 1.0 semantics becuase XForms 1.0 semantics is not defined in the XForms 1.0
John Boyer: So we need to remove the "default value = 1.0" text.
Leigh Klotz: So we do that and we say that the version attribute is used by the host language integration to determine which XForms processor to run; the only behavior for a given XForms processor is that it throws an error if the processor cannot implement it.
Nick van den Bleeken: What about if we have 1.2 and it's compatible with 1.0 and 1.1?
John Boyer: I'm sensing a space-separated list.
Uli Lissé: I'm not sure I like the no-attribute version.
Leigh Klotz: Right now Chiba supports 1.0 or 1.1 or neither?
Uli Lissé: Something between?
Leigh Klotz: So neither. And the documents presently have no attribute, so that's current state.
Uli Lissé: Right
Leigh Klotz: But if it has version=1.0 you could stop doing the 1.1 behaviors?
Uli Lissé: Right, but I'm still uncomfortable.
Leigh Klotz: ...
Uli Lissé: ...
Leigh Klotz: There are many uncomfortable positions.
Uli Lissé: We should do like XSLT and be strict.
Leigh Klotz: But in xslt, if you leave off version="1.0" the 1.0 processor won't run it.
John Boyer: OK, Straw poll.
Steven Pemberton: OK.
Charlie Wiecha: No objection
Roger Perez: No objection
Keith Wells: I think it should do its best with no value.

Nick van den Bleeken: What about when 1.2 comes out?
John Boyer: So is space-separated list good?
Leigh Klotz: Is it OR or AND? We have to decide.
John Boyer: It's AND.
Leigh Klotz: If we change it from float-like things to NMTOKEN people will put foo-feature in and expect AND so we have to say specifically.
John Boyer: Then it turns into feature-codes.
Leigh Klotz: And nobody wants to urn:uid: feature codes.
Uli Lissé: I don't get it.
John Boyer: If it works in 1.0 and 1.1 and people put that in and it doesn't work in 1.2 then people need to put that in.
Uli Lissé: ...
John Boyer: So do we not want versioning?
Steven Pemberton: One option is to say that XForm is always compatible but that blocks you off from certain kinds of additions.
John Boyer: Or you keep having revisions of past specs.
Leigh Klotz: And retroactively declare people noconformant.
John Boyer: OK so we remove the default value of 1.0.
Leigh Klotz: If we make it a list type then it would be nice to make it a list of a simpleType rather than a pattern-based restriction.
John Boyer: Hopefull the type is already described and we just need a space-separated list of those.
Leigh Klotz: OK.
John Boyer: The model version attribute has a normative reference to XForms 1.0. The XForms Processor is a thing that may interpret more than one version of the language. I don't see how a user agent would choose.
Leigh Klotz: OK, so my proposal for implementing this won't work, splitting up the functionality. Are we still doing version not specified means version not specified?
John Boyer: I'm trying to.

Action 2007-06-14.4: John Boyer to fix formatting to relevant and validate attributes to submission.

* Editorial Issue 30

Action 2007-06-14.5: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Controls?id=30 John to delete the first "Description" in 8.1.5

* Editorial Issue 75

Action 2007-06-14.6: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Actions?id=75 John Boyer to delete extra double quote at end of example in http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Actions?id=75 (PR actions/75)

* Editorial Issue 39

Action 2007-06-14.7: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=39 John Boyer to change in section 7.5.3 UI Binding Expressions 'Dynamic dependences' by 'Dynamic dependencies', issue XPath/39

* XForms Meeting in Madrid

John Boyer: We need to have the discussion before Roger leaves for his flight, which is a bit earlier tomorrow.
Steven Pemberton: Roger, you said the date would work for you?
Roger Perez: Yes, but we would like to move it.
Steven Pemberton: It's been this date for more than a year now and people have made arrangements. I for one would prefer not to renegotiate those dates.
Roger Perez: He said he would like to move it because of holidays.
Steven Pemberton: Also the next meeting is eight weeks after that, between September and November. We also have the issue of which days we would like to meet at the Cambridge meeting. Are we going to meet on Saturday, for instance? The meetings start Thursday and run until Saturday at lunchtime?

* Editorial Issue 40

Action 2007-06-14.8: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=40 John to change in section 7.6 The XForms Function Library 'xforms-binding exception' by xforms-binding-exception missing -, issue XPath/40

* Description of Differences with 1.0

Steven Pemberton: Should I accept this?
John Boyer: We had a thin spec, then last call. That's the difference.
Steven Pemberton: They want to know about changes to insert and delete processing, not spelling changes with hyphens.
Leigh Klotz: John, is your objection to having it writing it?
John Boyer: Writing it, I guess.
Steven Pemberton: I have some notes. Let me find them. http://www.w3.org/2007/Talks/05-15-steven-xforms11/#xforms11

John Boyer: Do you have the XTech talk for me to add to the XForms publications list?
Steven Pemberton: http://www.w3.org/2007/Talks/05-15-steven-xforms11/

Steven Pemberton: http://www.ebaymobile.co.uk uses XForms, server-side.

* Editorial Issue 31

Action 2007-06-14.9: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Actions?id=31, John Boyer to change in section 10.14 Conditional Execution of XForms Actions second triger tag has wrong closing tag ( instead of ), issue Actions/31

* Editorial Issue 35

Action 2007-06-14.10: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Misc?id=35 John Boyer to fix 8 typos reported by Gary F Stevens, issue Misc/35

* Document Versioning


John Boyer: Mark, there's your proposal for the root element attribute, and the underlying thing that people have to know too much about version boundaries to get their forms to work. We've attempted to relax the version checking to accomodate. The first thing to note is that the default is now empty string. Empty string is synonymous with no version setting; then the forms processor is free to use whatever conformance level is available to it. The attribute would have a space-separated list of zero or more version strings. If one or more versions is indicated, then the processor gives an error if doesn't support any of them.
Mark Birbeck: So it wouldn't work on a 1.2 processor?
John Boyer: Only if it doesn't support 1.0 or 1.1.
Mark Birbeck: So it's a mode.
John Boyer: Yes. If more than one is specified it can pick any level it wants. There's one more thing I'll fix. Then I scratched out the note because we removed the normative reference and Uli said he could live with this if we added this to 1.0 as well.
Mark Birbeck: OK.
John Boyer: I accidently deleted the version exception if the version-setting is on a non-default model which conflicts with the default model.
Leigh Klotz: It seems to me if the default model has no constraints and the other two models have "1.0 1.1" and "1.1" then the constraint is solvable.
John Boyer: But not in other cases. It's easy enough to make your models consistent. We had this contraint before that all must be equal.
Charlie Wiecha: That breaks the portal case.
John Boyer: It was broken before.

* XForms 1.0 to 1.1 changes

Steven Pemberton: Should we put the introduction into the spec?
John Boyer: No
Leigh Klotz: A note, like XForms for HTML Authors
Steven Pemberton: But as a service to the reader?
Leigh Klotz: A link?
John Boyer: An informative one.

* Document Versioning


Leigh Klotz: So it still doesn't define "conflict." Is it not equal?
John Boyer: Not equal.
Leigh Klotz: So if the first model says version="1.0 1.1" and the second says nothing then it's a conflict.
John Boyer: Yes.
John Boyer: If the second model says 1.1 and the first doesn't care, that's a conflict
Leigh Klotz: I worry about the other case. The first model can set the version, but the other models should conflict.
John Boyer: OK. But the error should go to the first model.
Leigh Klotz: OK.
Mark Birbeck: I really like this functionality but is the name version ok? Mode or processor?
Nick van den Bleeken: It's like supported-versions.
Mark Birbeck: "There are two ways of processing this; please use this one." You're saying something about how you want the document processed, not about the document. That's right.
Leigh Klotz: A minute ago you said this was for copy and paste and not understanding.
Mark Birbeck: I'm imagining this will be used by more experienced programmers. I think this still does that.

* Editorial Issue 54

Action 2007-06-14.11: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Submission?id=54 John to change in section '11.6 The resource Element and Attribute' change 'first child,' to 'first child element,' (second occurance of first child in this section), issue Submission/54

* Section 5.2.3 datatypes from Michael Kay


Keith Wells: How do we respond?
John Boyer: We already said defer to future on this because we don't know how to get the types out of the XSD namespace from XSLT 2. We now use the names in the XForms namespace by default, if not prefixed, so our solution works out better for XForms authors anyway.
Steven Pemberton: We have an xforms:yearMonthDuration. These are now allowed to be empty? We should be clear.
Keith Wells: Those are not listed under section 5.2.7.
John Boyer: We overlooked them. listItems should allow empty as select uses it.
Steven Pemberton: It covers zero if list covers zero.
Leigh Klotz: It looks like it does.

Nick van den Bleeken: ...
Steven Pemberton: ...
John Boyer: We built the corresponding datatypes to allow empty strings. We didn't look at our datatypes.
Steven Pemberton: Otherwise, required doesn't work. My feeling is that everything in the XForms namespace ought to allow empty.
John Boyer: Are there any datatypes other than those six: listItem, listItems, dayTimeDuration, yearMonthDuration, email, and idCard.
Leigh Klotz: So a listItems is a set of space-separated empty strings?
John Boyer: We have a real problem with select and select1 and empty values. We keep having this debate. David has a use case with a select1 and an item with a label and a value. So a select of a copy matches empty because the XPath text value of the complex content is the empty string. It's a design limitation around select and select1. For listItem and listItems you would use that but if you try to use a type MIP to assign them to a node, would you then ref that node with a select or select1? The argument about empty is required. But it is a MIP used with a ref.
Steven Pemberton: Nobody really does this.
Leigh Klotz: Let's check the data binding restrictions. It does say it is "facilitating."
Leigh Klotz: So are we going to change listItem to be empty?
John Boyer: We are. listItems then is a union with empty string.

Action 2007-06-14.12: Mark Birbeck to update schema and text for listItem and listItems to support empty content; we suspect that listItems will have to be a union with empty string.

* Document Versioning

John Boyer: So here is the new text.
Leigh Klotz: It says conflict in one place and compatible in anothger.
John Boyer: OK. Compatible and incompatible. Anybody have a conflict or incompatibility with this text?
Leigh Klotz: OK.
John Boyer: I think it's good John.

Resolution 2007-06-14.6: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Model?id=104 , we change section 3.3.1 to default model version to empty, and define empty to mean that the processor gets to choose the version. If no version chosen is available, the xforms-version-exception is dispatched to the default model. The declaration on the default model is used to make the choice. Later models may offer declarations of model version but xforms-version-exception is dispatched to the default model if their declarations are incompatible with the version chosen.

* Editorial Issue 22


Steven Pemberton: "already allowed" and "indicated". I'll put the update text in the issue.
John Boyer: OK.
Leigh Klotz: Let's get rid of the two lists, and list only our types and define the others by exception. Let's remove the quasi-basic asterisks and language. Then we have only one list.

* Editorial Issue 138


Keith Wells: Michael Kay has the same issue, but wants more information.

Resolution 2007-06-14.7: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Types?id=22, and http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Types?id=22, they all accept empty; we are fixing the confusing text.

* Editorial Issue 79


Action 2007-06-14.13: John to remove in after within in section '11.2 The xforms-submit Event' (action processing is blocked within in the default processing), issue Submission/79

* double type


Keith Wells: Michael Kay points out there is no * next to xsd:double.
John Boyer: That's an XForms Basic issue.
Leigh Klotz: It's not XForms Basic; that's another spec. We just removed the list.
Steven Pemberton: And XForms Basic does not have double.
Leigh Klotz: But XForms 1.1 might. Let's move the list of xforms types up.
Steven Pemberton: And with or without a namespace.

Resolution 2007-06-14.8: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Types?id=136 , we remove the asterisks and the table of xsd types and replace it with mention of XSD types, no indication of what XForms 1.0 Basic Profile might or might not do, and a table of xforms-namespace datatypes.

* Empty Types


Resolution 2007-06-14.9: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Types?id=98 We approve.

Action 2007-06-14.14: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Types?id=98 , John Boyer to update to update the listItem, listItems timeDuration, email, and card to types in XML Schema and text to allow empty content.

Action 2007-06-14.15: Mark Birbeck to update schema for email to to wrap regexp pattern in (...)?

* Restriction of international mail addresses unclear


Steven Pemberton: There's a problem between lexical space and value space. He says that in http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Types?id=6

Resolution 2007-06-14.10: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Types?id=6 we respond that we accept and will be clearer, but there is something in section 6 already.
John Boyer: Do we convert here? What's the pattern? What's the common practice?
John Boyer: Should we convert to the RFC 2822 space or not?
Steven Pemberton: Do we conver tto space here or should we use Unicode email addresses? I will ask him.

Resolution 2007-06-14.11: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Types?id=10 we respond that we would like to a regular expression that matches email addresses including international ones (both left and right of @).

Action 2007-06-14.16: Charlie Wiecha to look up lexical and value space for http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Types?id=6 and http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Types?id=6 and confirm lexical/value space and provide the email screenshot for 8.1.2 input control and spec text for the conversion for international email addresses.

* Meeting Ends