W3C Forms teleconference February 1, 2012

* Present

Nick van den Bleeken, Inventive Designers
Steven Pemberton, CWI (chair)
Leigh Klotz, Xerox (minutes)
Alain Couthures, AgenceXML
Uli Lissé, DreamLabs
Erik Bruchez, Orbeon

* Agenda


* Future of XBL


Steven Pemberton: From John Thomas or Rand McRanderson.
Leigh Klotz: If he's interested in helping, we'd be happy to help him. It's easy to interface with JavaScript APIs through XForms already, in both client-side and server/client implementations of XFOrms.
Erik Bruchez: We have some ideas, keep developing XBL or develop a lightweight XBL that would be future-proof with the HTML component model, but the WG has no plans to work on it at this time.
Steven Pemberton: So let's answer like that.

ACTION-1861 Steven to answer XBL question at http://lists.w3.org/Archives/Public/public-forms/2012Jan/0025.html

* Appearance on help, hint, label

http://lists.w3.org/Archives/Public/public-forms/2012Jan/0013.html http://lists.w3.org/Archives/Public/public-forms/2012Jan/0021.html

Steven Pemberton: Someone needs to define this behavior in the spec.
Leigh Klotz: Unless Erik wants to do it I will.

ACTION-1860 Leigh Klotz to do define appearance on help, hint, label as in http://lists.w3.org/Archives/Public/public-forms/2012Jan/0013.html http://lists.w3.org/Archives/Public/public-forms/2012Jan/0013.html

* Identifying Application State (TAG)

http://lists.w3.org/Archives/Public/public-forms/2012Jan/0014.html http://lists.w3.org/Archives/Public/public-forms/2012Jan/att-0018/2012-01-18.html#topic6

Steven Pemberton: We don't have a design. We should just push that on the future stack.
Leigh Klotz: I added it to XFormsFutureFeatures http://www.w3.org/MarkUp/Forms/wiki/Hashtags_and_State

* submission/@replace="text" / Encoded as text

http://lists.w3.org/Archives/Public/public-forms/2011Dec/0018.html http://lists.w3.org/Archives/Public/public-forms/2011Dec/0016.html

Steven Pemberton: There are two halves: if the replace text in a subtree, and that text is XML do we encode it as text? Is that so obvious that we don't need to define it?
Leigh Klotz: If the mediatype is an XML mediatype?
Steven Pemberton: Yes.
Leigh Klotz: Don't you just ignore the mediaType?
Alain Couthures: Yes.
Erik Bruchez: It seems like we support that.
Steven Pemberton: What does "encoded as text" mean?
Erik Bruchez: If it's text/* or json we read it in a charset. If it's XML including not text/xml (i.e. application/xml) then we read that.
Steven Pemberton: Do you take the child nodes and extract the text?
Erik Bruchez: No, the whole thing. We recognize XML and JSON as text. replace="text" is pretty clear; you set the string value into the resulting DOM.
Steven Pemberton: I had intepreted it differently. I imagined that "encoding as text" meant taking the text child nodes. You just take the XML as as string.
Steven Pemberton: What if it is an XHTML response?
Erik Bruchez: It is read as a string and replaced as text where the targetref is pointing, with no parsing going on.
Nick van: You can then use the textarea control with mediatype text/html to edit that.
Steven Pemberton: So you replace left open bracket with ampersand-less than and such?
Leigh Klotz: That's how it would come out serialized; for the DOM you just create a text node and put it in there.
Erik Bruchez: There are a few disallowed control characters, disallowed for no reason. Most likely your DOM character wouldn't care, but the others are stored as-is. In serialization as XML 1.0 then you get them serialized with some escapes.
Steven Pemberton: So we think that "encoded as text" is enough?
Leigh Klotz: It might better to use that the response is used as received.
Erik Bruchez: You have to allow for processing charsets. What if you receive text/plain with UTF-16? You still have to process the results.
Steven Pemberton: Yes, I guess those are just details. I have to admit I'd misinterpreted this and maybe there should be some text that makes it clearer what "encoding as text" means.
Erik Bruchez: I think the spec is fairly clear. It talks about replace=text and replace=instance. That overrides everything else. The XML type is orthogonal if it's replace=text.
Steven Pemberton: I thought you'd get just the text.
Erik Bruchez: I can see why you would want that, but the spec doesn't say to parse the text as XML.
Steven Pemberton: I didn't know what encode meant. If we're agreed that it's the literal text of the XML document, we should say that more clearly. ACTION-1859 - Steven Pemberton to clarify "encode as text" for replace="text"

Steven Pemberton: So there's no reason to reject any text media types.
Leigh Klotz: You could even accept some image types, such as SVG and XBM.
Steven Pemberton: And other application types as well.
Erik Bruchez: We also look at the application/json type. It would make sense because you could then process JSON as text using extensions.
Leigh Klotz: Why do we have this restriction on mediatype anyway? We could just say what to do if you get back binary stuff?
Erik Bruchez: Yes, mediatype seems to have lost some favor. We could be somewhat interoperable. We could leave the door open to other content.
Leigh Klotz: I think there are characters that fit in JSON that don't fit in XML.
Erik Bruchez: So if you can't read it as text, just fail?
Leigh Klotz: Right. And if you want the mediaType, get it from the response header.
Erik Bruchez: What about the spec-text about replace=instance? It says it must conform to an XML mediatype. It's the same story. Why do we need the mediaType? It could application/xml, text/xml, text/xml with encoding? What if you say replace=instance and the mediaType is image/jpeg should it try? It's the same story.
Steven Pemberton: What would we do with image/jpeg?
Erik Bruchez: If your server sends image/jpeg and it's not binary content and it's a mistake. Right now we say you must first look at the mediaType.
Leigh Klotz: Just giving an error if it's the wrong mediatype isn't useful. What's useful is changing behavior, for example, handling XML or JSON on replace=instance.
Erik Bruchez: I was thinking of the text/json case; with replace=instance we might convert that to XML.
Leigh Klotz: I don't think just checking for errors is useful.
Erik Bruchez: You could sniff both and run various parsers. How far do you go? You might not consider the mediatype the ultimate source of truth? We were looking at relaxing the spec text on text, we might want to look at the XML mediatype as well.
Steven Pemberton: When I'm trying to solve this text probelm I'll review the situation there and see if it can be loosened up in some way.

* XForms 2.0 and XPath


Leigh Klotz: I think we should stop discussing the XPath 1 implications of every single thing. I think it is an implementation problem at this point.
Erik Bruchez: What about XSLTForms and John's implementation?
Leigh Klotz: They might not be fully compliant XForms 2 implementations without XPath 2.
Steven Pemberton: Alain?
Alain Couthures: I will be presenting at XML Prague about XPath 2.
Leigh Klotz: I think it's OK to have XForms 2 features with XPath 1 and just call it not a full implementation.
Erik Bruchez: Should we wait for John?
Leigh Klotz: John said with XForms 1.2 it was a bigger deal than with XForms 2.0.
Steven Pemberton: We can wait for John, but anyone here object? Speak up now. No?

* Why is https: optional?


Erik Bruchez: I can only imagine very limited implementations of XForms without HTTPS. The web is moving more to HTTPS.
Nick van: Yes.
Steven Pemberton: Any objections to making HTTPS required?

Resolution 2012-02-1.1: HTTPS is required for XForms 2.0

* AVT in XForms (Review Spec)


Leigh Klotz: I know we can't use AVT with ID, but we can use AVT where we have IDREF, is that right.
Nick van: In the host language, it is up to the host language.
Leigh Klotz: As in dispatch.
Nick van: I see no problem having an AVT in IDREF in XForms but it may require some surgery because of listeners. It's evaluated when the action is run.
Leigh Klotz: An you do this? <dispatch targetid="{foo}" name="xforms-submit" />
Nick van: I think so. I think we should prohibit AVTs in the @model attribute.

ACTION-1862 Nick van den Bleeken to double check XForms 2.0 AVT for places where we use IDREF.

ACTION-1863 Nick van den Bleeken to email group a list of attributes that don't support AVT, in a summary list to the group.

* JSON/mediatypes/src/replace


Steven Pemberton: This is related to what we've been talking about.
Steven Pemberton: We had said that if it comes in as JSON it gets submitted as JSON, as when you load/save images from image editing programs. Is a submission always XML or is it dependent on what the data came in as.
Leigh Klotz: I would think you should have to serialize it as application/xml unless you say otherwise, because I could see that ref= subaddressing of JSON turned into XML could not be serialized back as JSON. We have method="post" as XML and method="urlencoded-post" as application/x-www-urlencoded. But maybe Alain has a different point of view.
Alain Couthures: I believe requiring mediaType is necessary.

Resolution 2012-02-1.2: Even with instance populated from JSON submission response, submission back from that instance still obeys regular submission rules, e.g. post implies application/xml, unless an explicity mediatype attribute is used on submission.

* No IRC Minutes

Not made due to failure with rrsagent

* Meeting Ends