Nick van den Bleeken, Inventive Designers
Steven Pemberton, CWI (chair)
Leigh Klotz, Xerox (minutes)
Alain Couthures, AgenceXML
Uli Lissé, DreamLabs
Erik Bruchez, Orbeon
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
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
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
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.
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?
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
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.
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.