Charlie Wiecha, IBM
Erik Bruchez, Orbeon
John Boyer, IBM (chair)
Mark Birbeck, x-port.net
Roger Pérez, SATEC
Uli Lissé, DreamLabs
Keith Wells, IBM
Leigh Klotz, Xerox (minutes)
http://lists.w3.org/Archives/Public/public-forms/2008Apr/0104.html
John Boyer: Next week, Nick is chairing. I'll be providing Nick the materials for the agenda, which he will make.
John Boyer: We claim it's June
9-12.
Leigh Klotz: The page at http://www.w3.org/MarkUp/Forms/wiki/FtF_2008_06
said June 9-11 for a while but I checked with Steven.
John Boyer: He must have updated it.
Also Erik wanted to know which days were Forms.
Charlie Wiecha: All of them,
now.
John Boyer: Yes, no HTML days.
Charlie Wiecha: The kickoff call is the May 16th 10:00 AM eastern. Check with your AC rep to join.
John Boyer: I may be below the
10-item list, but Nick, please produce another copy with the
changes from Charlie, Mark, and myself.
Leigh Klotz: I sent a message to the
Felix Sasaki of ITS and asked if we were done, but got no response
so I can't close that action yet.
John Boyer: I sent a note to PicoForms
about the test suite; and Steven isn't here because of the Queen's
Day holiday.
John Boyer: There's a resource
attribute and a resource child element of submission. It used to
appear on the load action. This is a name conflict with RDFa. To
the extent that we hope that XForms syntax can be used in XHTML
without qualification, we need to address this.
Charlie Wiecha: It seems like RDFa has
priority on the attribute. I agree with the thread.
John Boyer: I never did like the word
"resource" for submission. It would have been best to have two
types of action subelements; a local element with a value and
global element with a container and handler.
Leigh Klotz: [irc] "An important principle of Web architecture is that all important resources be identifiable by URI. The finding discusses the relationship between the URI addressability of a resource and the choice between HTTP GET and POST methods with HTTP URIs. " http://www.w3.org/2001/tag/doc/whenToUseGet.html
John Boyer: The resource child
attribute has a value. Could we have a local child action element
that could have the value, and a global action with ev:event.
Mark Birbeck: You could, but the
second couldn't appear as a child of submission, which is a shame,
since you want action handlers on the child element. You can't
differentiate on the basis of attributes in XML Schema. However,
there is another possible longer term thing; when I was working on
XML Events 2, I took the liberty of adding ev:action. Maybe we
would consider deprecating our action instead.
Leigh Klotz: But that brings up the
different namespaces again.
Mark Birbeck: XML Events also would be
a module.
John Boyer: The action name has also
always been, um, bad, as well. But what to we rename it to? It
looks like action is a bit of a problem?
Leigh Klotz: I proposed the name
resource from the TAG finding above so I think it's appropriate to
say we can POST to a resource.
Mark Birbeck: The problem is that RDFa
uses resource.
Leigh Klotz: That's OK to use it at a
higher semantic level, but my point is that it's not inappropriate
to be able to POST to a resource.
Mark Birbeck: RDFa's usage is
broader.
John Boyer: Is there a conflict with
submission?
Mark Birbeck: Here's an idea; maybe we
just leverage it in a future version of RDFa, just as we have with
img. We add a semantic interpretation to existing markup. If
someone does rel="stylesheet", we say we can interpret that as an
RDF statement saying that the document has a property of
stylesheet, and here's the pointer. The first step with RDFa is to
re-use attributes that you already use. So src on img is an
existing HTML attribute which we give an RDF twist. If this
resource attribute were already used in XForms and we came out with
RDFa2, we'd go through the attributes and see if any had an obvious
semantic meaning. We'd look at load/@resource, and say that it has
a relationship of loads-external-program with this other document.
Given that the RDF interpretation would then be the same as the
RDFa interpretation, it might not be a problem at all.
John Boyer: That sounds good. And it's
applicable for instance as well?
Leigh Klotz: If RDFa can be that
flexible, that's a big point over XLink.
Mark Birbeck: RDFa 1 wouldn't do that;
it would treat it as its own resource attribute, but I'm not sure
that's a problem. It is unlikely that RDFa is going to go through
life without resolving these issues.
John Boyer: So the discussion is that
we leave the name for now?
Mark Birbeck: If someone came up with
a brilliant new name, that would be great. So I'm wonder whether we
should leave it. We should raise it with the RDFa group, but I
reckon it would be OK, if we perform the thought experiment of what
it would be in a year.
John Boyer: Can you do the action? Is
it a last call comment?
Mark Birbeck: It wouldn't be a
last-call comment, at least from me, to change the name for
RDFa.
John Boyer: Not change the name, but
just have the group consider the discussion?
Mark Birbeck: OK.
Action 2008-04-30.1: Mark Birbeck to raise issue of leaving XForms submission resource attribute alone and perhaps having RDFa document its semantics in a future version.
John Boyer: We gave Steven the
action to come up with the name. I came across some language that
said response might not be a bad name, but there was some
discussion that it might. So let's discuss the name response. It
would provide an XPath that says where, within the instance data,
the submission response goes.
Erik Bruchez: I don't have a
super-strong feeling. I was pointing that as Leigh had with
resource, response in HTTP includes the status code and headers. We
follow that concept in the XForms submit-done context information
which allows getting the response status code.
John Boyer: The headers are
response-headers.
Erik Bruchez: So technically it is the
response-body not the response.
John Boyer: Any other names come to
mind?
Charlie Wiecha: It's kind of ugly, but
response-body or response-data would clarify it?
Leigh Klotz: Does it need to be
clarified?
Charlie Wiecha: Do we need to add the
specificity or do we tolerate the ambiguity for a simpler attribute
name?
John Boyer: Following our chain of
thinking here...in the submission, the problem is that we have
replace=instance rather than replace=xpath. Then we
have an instance attribute which takes an idref. I'm wondering
again with a local element if it might not be possible to solve
this with a child element of submission called instance. The other
places where we've added child elements with value attributes, so
we could use instance/@value to calculate the id of the instance;
on the other hand, if we provide a child instance element with a
ref, then we specify the node instance to replace.
<submission... <instance value="blah" />gets the value of blah and uses as IDREF overload of instance attr but
<instance ref="blah" />would instead overload by pointing to actual instance data
response-body on xforms-submit-done, we could write
<setvalue ev:event="xforms-submit-done" ref="/foo/bar"
value="event(response-body)"/>. We have it for
xforms-submit-error but not xforms-submit-done. So if our proposed
solution is longer than this we aren't achieving anything great.
foo)/foo/bar" /> foo)/foo/bar" /> IDREF. all
is the default so if we're after streamlining, the behavior of
replace=all in 1.2 could be further augmented by a
target attribute. It's the most natural thing if the author already
understands target idref. text and have an XPath
expression for the target. target was proposed to replace a part of the
document. all for that as it is the default. x or the dom element with
id=x so you'd use all for frame and target for
document. foo" all? some
all should use target as in html. If not, it
doesn't solve the problem. instance or
replace=text? In those cases, it's XPath. Resolution 2008-04-30.1: We revoke our previous resolution and keep submission/@target as is, since we now understand that in the future we may take advantage of other attributes and XSLT 2.0 doc() function to refer to parts of the host document.
John Boyer: So no second last call!
John Boyer: In XForms 1.0 SE the
xforms-validate event was rewritten to exclude the validate
attribute. So events are invalid with constraint or type (however
specified) but there's no validity check on required-but-empty.
Simultaneously, we redefined submission-validation to incorporate
validity from the revalidate event and also accommodated the
required-but-empty. So submission validation checks for required
and stops if the node is empty. The problem Erik has raised is that
we never said that the cumulative process is equal to submission
validation, so there's an ambiguity with submission/@validate that
it should turn off the required-but-empty condition checking. My
proposed change would be editorial, that we retain the word
"validate" but do a better job of defining submission validity. We
need the proper rigorous definition.
Erik Bruchez: It seems to be the
easiest fix; I've been confused for years. I've explained it to
people, but I don't understand why the decision was made to say
that required-but-invalid is a different concept, except for
submission.
John Boyer: I wasn't happy with the
choice either. If you include the required-but-empty condition you
get what some thought was an unfavorable user experience from
xforms-invalid event handlers. There's no way in CSS to handle the
invalid displays only if it's not empty.
Charlie Wiecha: [irc] wasn't it for
form startup?
Erik Bruchez: We had no MIP events
sent when the page initialized though.
John Boyer: In XForms 1.0 we had no
@if.
Erik Bruchez: We have extension
context events. There's more that needs to be added if you want to
cover the cases.
John Boyer: It's not too hard to get
the value of the node using ".".
Erik Bruchez: You want context info
for a single event handlers, not 400 of them.
John Boyer: I'm not sure we expose
enough.
Erik Bruchez: We don't; you need more.
...
John Boyer: So you pointed out the
processing model for the events has been clarified so the usability
concern doesn't exist any more. So maybe we go back and fix
validity.
Erik Bruchez: Yes, say invalid if
required-but-empty and remove the text from submission, and we get
a single idea of validity.
Leigh Klotz: Everybody wants non-empty
leaf nodes not to be checked for validity if they are not required.
The union types are a bit of a crock fix.
Erik Bruchez: I know what you mean,
but it's the other side of the coin.
Leigh Klotz: We should consider them
at the same time though if we're making changes on
required-but-empty.
John Boyer: Some of the implementers
aren't available. I think it was Chiba, but somebody said that they
were hooking those events to CSS pseudo-properties and getting CSS
for something being invalid when it was required-but-empty.
Erik Bruchez: My problem is that I
couldn't style required-but-empty. We hack around to get it.
John Boyer: If you style for required
and invalid....
Erik Bruchez: Required and empty
doesn't. In CSS you can't get to the value of the node.
John Boyer: The objection was from a
usability standpoint. If you had a big red X over the invalid
things, then from the get-go the claim was you'd get big red
X's.
Erik Bruchez: That's a use case that
should be covered. But I'd like to mark the required fields when
required but empty.
John Boyer: And your earlier point
that events don't fire on startup anyway.
Erik Bruchez: We need a solution that
addresses both cases.
John Boyer: This topic needs further
work. It sounds like we need more discussion of this problem.
John Boyer: I won't be available for next week's call.