W3C Forms teleconference Octobober 17, 2007

* Present

Blake Joes, ViewPlus/DAISY
Charlie Wiecha, IBM
Erik Bruchez, Orbeon
John Boyer, IBM (chair)
Leigh Klotz, Xerox (minutes)
Lars Opperman, Sun
Mark Birbeck, x-port.net
Nick van den Bleeken, Inventive Designers
Roger Pérez, SATEC
Uli Lissé, DreamLabs
Keith Wells, IBM

* Agenda


* Previous minutes:

http://lists.w3.org/Archives/Public/public-forms/2007Oct/0046.html IRC supplement: http://www.w3.org/2007/10/10-forms-minutes.html

* Latest Action Item List


* Next FtF


John Boyer: The next F2F meeting is in November; October 19th is the deadline for registration.
Leigh Klotz: I won't be attending in person, but by phone.
Lars Opperman: I also won't be attending.
John Boyer: Please register and come if at all possible.

* XForms 1.0 Third Edition

http://www.w3.org/TR/2007/PER-xforms-20070725/ http://lists.w3.org/Archives/Public/public-forms/2007Oct/0056.html

John Boyer: I'm waiting for Steven to make the request to get on the director's calendar, but we don't think they'll need a meeting. We're hoping for the end of the month.

* XForms Conference at XML Conference


John Boyer: Get out and blog this. We're getting questions about it; one is "How open is it?" I had thought it was open to anyone attending the conference.
Charlie Wiecha: That was my expectation.
John Boyer: They're asking if it's open to the public as well.
Charlie Wiecha: It's a matter of having to register with the conference itself.
John Boyer: They said they'd let it be open to the public and put out a separate signup sheet.
Leigh Klotz: Then there's no pressure to close it.
John Boyer: I'll do that then.
Mark Birbeck: [leaves with apologies]
John Boyer: We don't have a clear idea how many are attending but we'll ask to prepare for a larger room, as there will be no conflicting events.

* Anyone to answer these?

http://lists.w3.org/Archives/Public/www-forms/2007Oct/0003.html http://lists.w3.org/Archives/Public/www-forms/2007Oct/0000.html http://lists.w3.org/Archives/Public/www-forms/2007Sep/0006.html http://lists.w3.org/Archives/Public/www-forms/2007Sep/0001.html

John Boyer: We need someone to answer these.
John Boyer: Would someone answer the first one, a function to get the query string? He's forwarded it from his www-dom message.
Leigh Klotz: I can answer this from the XForms perspective.

Action 2007-10-17.1: Leigh Klotz to answer http://lists.w3.org/Archives/Public/www-forms/2007Oct/0003.html from the XForms perspective.

John Boyer: The next one is the copy element. Anybody? Erik?
Erik Bruchez: I'm looking...I have some questions myself.
John Boyer: If you have questions, post them here. If you have difficulty then we definitely need to know about it.

Action 2007-10-17.2: Erik Bruchez to answer http://lists.w3.org/Archives/Public/www-forms/2007Oct/0000.html

* XForms:instance requests, the HTTP Accept header and RESTful Web Services...


Leigh Klotz: Isn't this just a Mozilla bug? Mozilla should be sending only xml requests. However, we do need a way to specify the accept content type in XForms 1.1 if we don't already because we can accept non-XML responses.
Nick van: Submission already has this.
Leigh Klotz: What about instance/@src?
Nick van: That's always XML.
Leigh Klotz: Oh.
Lars Opperman: There can be other types.
Leigh Klotz: You mean text/xml or application/*+xml?
Lars Opperman: Or text/plain and parse it anyway, though that might be an edge case.
John Boyer: Can someone write these up?
Lars Opperman: I can do that.

Action 2007-10-17.3: Lars Opperman to write up suggested changes to XForms 1.1 in response to http://lists.w3.org/Archives/Public/www-forms/2007Sep/0006.html

* FAQ comment; About seccion, Will we have to wait for new browsers?


Leigh Klotz: We have an implementation status page.
John Boyer: I think he's talking about the wiki. I can take a stab at answering this on unless someone else would like to do it.

Action 2007-10-17.4: John Boyer to answer http://lists.w3.org/Archives/Public/www-forms/2007Sep/0001.html

* Completion of insert/delete examples.


* Completion of submission examples

http://lists.w3.org/Archives/Public/public-forms/2007Oct/0022.html (action-->resource, spec sections and locations, spec xml?)

Leigh Klotz: That's mine. I'm confused; am I supposed to write new examples?
John Boyer: Just a brief SOAP example, which I can do. And modulo the GET default.

Action 2007-10-17.5: John Boyer to produce simple SOAP submission example.

* A default for submission method

http://lists.w3.org/Archives/Public/public-forms/2007Oct/0043.html http://lists.w3.org/Archives/Public/public-forms/2007Oct/0041.html http://lists.w3.org/Archives/Public/public-forms/2007Oct/0032.html http://lists.w3.org/Archives/Public/public-forms/2007Oct/0021.html

John Boyer: We got Erik's response and not much else.
Leigh Klotz: I reported that we had originally said post but removed it.
John Boyer: I kind of like the specificity, and would selfishly not like to create another work item for myself. Is there anyone who strongly feels we have to get rid of method=get?
Leigh Klotz: To me this sounds like a next-gen/transitional issue.
Nick van: [irc] I don't have a real opinion about this.
John Boyer: Sensing silence here, it doesn't sound like there are strong feelings here.

Resolution 2007-10-17.1: We leave the issue of default method=get for a future release.

* Behavior of src attribute when instance content or resource is defined


John Boyer: Steven's not here, but I'll raise it briefly. I think there was some understanding that the src link on an instance, if it failed, the XForms processor might fail-over to using internal instance data; but that isn't what happens; you get an xforms-link-exception.
Nick van: [irc] I always thought that the exception was raised
John Boyer: Nick is correct; I thought it would be useful to have a failover. Does anyone on the phone care enough to propose spec-ready text?
John Boyer: I sense that as not wanting to proceed; if Steven cares he can raise it but I'll consider the matter closed for now.

* Nillable complex type with simple content


John Boyer: This is a last-call issue.
Erik Bruchez: First, I wanted to make sure that I had an example of acomplexType with simpleContent.
John Boyer: I agree, that looks correct to me.
Erik Bruchez: The second part is that the type now has nillable=true, so if the author puts an xsi:nil="true" in the instance, is this meant to work as in XML Schema. One of our users asked; we don't implement this. It seems like xsi:nil isn't related to the validity of the element and not just the datatype part.
John Boyer: If you say xsi:nil="true" doesn't that mean that not only can it accept empty but that state is invalid unless it is empty. I thought you had to have the attribute changing its value to reflect what the content actually was. We can do that with a calculate.
Erik Bruchez: I'm not sure it does that; by simpleContents...what my type example does is that defines the contents of the element in two parts: one part is an base type of state values and in addition adds an attribute to the element. Clearly to me, the attribute is not going to be validated. It would still validate the datatypes. This example uses an extension nillable=true. If I were to have an empty content, it would still be valid because it's allowed to be nillable. So an empty string would still validate as true in XML Schema. If I don't put xsi:nil="true" then I would be invalid.
John Boyer: Am I right in guessing that xsi:null=true is attached to the element than to the simpleContent declaration?
Erik Bruchez: I don't think you can put it on the simpleContent.
John Boyer: It seems to be a statement about the content element but it is a statement about the content of the element.
Erik Bruchez: My understanding, not very advanced, is that I would expect this to related to the textual content of the element. That appears to be a constraint on the content of the element. The user would assuem that nillable=true would do something, but the Schema specs says it determines the validity of the element, so it's not pure dataType validation. On one hand you have a strict datatype declaration...
Nick van: If you have that type that Erik defines and you assign it to the element state it would be invalid XML; the parser would not allow it. It's not consistent to specify a type. If you have a schema and that schema says that state is of this complexType state-element then this piece of XML will not validate according to the schema; no content is allowed if xsi:nil=true.
Erik Bruchez: That is true. There may be other things like this. One problem we have in XForms which we postponed was when the XForms engine performs a full Schema validation and when it performs datatype validation.
Leigh Klotz: Is this an issue about bind type assignment? Schema validation isn't done at instance load time.
Erik Bruchez: In this case you're binding this type to the element. Is the type property marking the node as valid or invalid in this case? If you just perform the type MIP validation, what is the result?
Leigh Klotz: We removed the copies of Schema facets and constraints such as minOccurs and maxOccurs but I had proposed a nillable one. Recently I proposed it as "optional" MIP which is like xs:nillable but means simply to type validate only if non-empty. That's a better solution than the union with empty string and we shoudld consider it for future versions of XForms.
John Boyer: Isn't that just "required"?
Leigh Klotz: No, it's a tri-state. Required means must be non-empty. If you don't say required=true() it defaults to required=false() and means that it may be empty, but if it's got a datatype, it cannot be empty. We need optional to mean type-validate if non-empty.
Erik Bruchez: ...
John Boyer: ...
Erik Bruchez: ...
John Boyer: Validation of a type MIP is datatype only, whenever you do it; whatever you get from simple content or simple type.
Erik Bruchez: Should we consider nillable then?
John Boyer: I didn't think there would be a difference in validation from UI and full validation.
Erik Bruchez: There would be, if this is part of a document, and I don't have it in my element, then full Schema validation would say it's invalid. Then I bind that siame type...
John Boyer: YOu have xs:element, name="state-element". Doesn't that mean that Schema will apply that complex type definition to elements named state-element?
Erik Bruchez: Right; it won't touch that particular element.
John Boyer: So that's badly named.
Erik Bruchez: I'm not sure that was intentional. Either it's part of the element or it's purely part of the data type. Or say it's friendlier.

Leigh Klotz: I have a contrarian view. This is a Schema problem and not ours, but unfortunately nillable is Schema structures so bind type can't use it. It will be caught on submission with XForms full but not otherwise. If you have xsi:nil out of sync with then content, then it's your fault as a form author and you should have, as John points out, use bind/@calculate to make sure it's always right.
Erik Bruchez: Doesn't sound contrarian to me.
Charlie Wiecha: ...
Erik Bruchez: ...
Leigh Klotz: Do we say we're not supposed to set xsi:nil when we submit?
John Boyer: We don't. The issue here though isn't about the valie of xsi:nil; it's about the association between the Schema type being done by type MIP only.
Leigh Klotz: Let's move on.
John Boyer: Let's add a note to the spec saying that nillable doesn't apply when applied through the type MIP, and respond to Erik.
Erik Bruchez: OK

Resolution 2007-10-17.2: We add a note to the spec saying that nillable doesn't apply when applied through the type MIP. http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Types?id=92

Action 2007-10-17.6: John Boyer to a note to the spec saying that nillable doesn't apply when applied through the type MIP and respond to message. http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Types?id=92

* Issues with datatype validation


John Boyer: I thought we'd answered this one already. We expect xsd:date to be there, even if not declared. Similarly for xsi:type. Does that seem reasonable to you, Erik?
Erik Bruchez: I think we may have discussed this at some point. I think Mark Birbeck was waiting on this as well. So we don't import a Schema but the xsi:type is processed, it increases our ties to Schema, and the document happens to contain xsi:type.
John Boyer: I think it has to be. We also have type MIPS without schema
Erik Bruchez: Yes, but that's just types. It doesn't apply to Relaxng, but types do. With XML Schema, we have funny things happening with xsi:type. My only concern was that if we don't import a schema, then I am wondering.
Leigh Klotz: We've already made this cut, it's XForms Basic. It supports XML Schema types but not XML Schema structures, just like Relax.
Erik Bruchez: But it's not Basic.
John Boyer: We say the XForms Schema is available.
Leigh Klotz: If you want to build a Schema-structures free version build it on XForms Basic.
Erik Bruchez: I don't want XForms Basic. If the form author import a Schema then we use xsi:schema.
Leigh Klotz: You can't retroactively take XML Schema out of XForms.
Erik Bruchez: In the future making it optional would be a good thing. It's not clear now when we process it; I don't get a feeling that it's all properly specified.
John Boyer: In the future we should control it on an instance-by-instance basis, but for now, it says all applicable Schema declarations are processed. What we're quibbling about is the definition of applicable. Nowhere does it say that if you don't import a Schema that you can leave it off.
Erik Bruchez: If the consensus is that it's clear then I have my answer.
Leigh Klotz: I agree with John that we don't say xsi:type isn't processed unless you import a Schema. We can't keep chipping away at this until we declare it broken and remove it. If we want to remove XML Schema we can do so in the future, and figure out how to support RNG. Let's discuss this at the next F2F and talk seriously about RNG and XML Schema support.
Erik Bruchez: I can report on this at the next F2F and talk about how XSLT 2.0 is looking at optimizations.
John Boyer: So for now let's treat this as a future request. Can you live with that Erik?
Erik Bruchez: Yes.

Resolution 2007-10-17.3: We answer http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Model?id=85 as a future request but make no changes to xsi:type which is processed regardless of whether a schema is imported.

Action 2007-10-17.7: John Boyer to repond to http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Model?id=85

* Meeting Ends

* IRC Minutes