Erik Bruchez, Orbeon
Leigh Klotz, Xerox (minutes)
Nick van den Bleeken, Inventive Designers
Steven Pemberton, CWI/W3C (chair)
Uli Lissé, DreamLabs
Charlie Wiecha, IBM
Alain Couthuries, AgenceXML
Steven Pemberton: Welcome
Alain.
Alain Couthuries: I have been working
with XML for ten years and am now developing XSLTForms. I've
rebuilt it from AJAXForms, and am now improving it, recently now
with native XML storage.
Steven Pemberton: We expect a few new
members to join but right now we're still building up to what we'll
be doing in the coming time.
Steven Pemberton: Next week is ok but in two weeks Leigh will chair.
Leigh Klotz: We should read this
with an eye toward what it means for XHTML+XML serving. XForms
implementations should review this because of the way that MIME
types work in different implementations.
Leigh Klotz: Also, it uses "normative"
and "MUST" in the RFC sense, but it says it's guidelines.
Steven Pemberton: I think most use
text/html for delivering documents. If you pull together we can
review it for formal comment.
Action 2010-06-9.1: Leigh Klotz to review HTML/XHTML Compatibility Authoring Guidelines to FPWG http://lists.w3.org/Archives/Public/public-forms/2010Jun/0002.html
Steven Pemberton: So we decided to work in the wiki for now and not have a monolithic spec, and thus not have a single editor. I did say I'd have a look at splitting it up into modules, but for the time being we've got the wiki.
Leigh Klotz: This validates the
approach; it lives outside MediaWiki and it converts Wiki text
markup to XML of various sorts. It doesn't convert to SpecML but we
could do that or we could write a converter for it. So it validates
the approach.
Charlie Wiecha: A template would be
nice too. A mockup of a module with examples for markup fragments,
tables, references, etc.
Steven Pemberton: Should we take
existing spec and wikify it?
Charlie Wiecha: That would be a good
reality check.
Steven Pemberton: Are you willing to
do that with a section?
Charlie Wiecha: OK.
Leigh Klotz: I will check it to make
sure it's convertible.
Action 2010-06-9.2: Charlie Wiecha to produce sample template for Wikified SpecML input with real examples from existing XForms Recommendation.
Steven Pemberton: Who will
summarize?
Erik Bruchez: We talked submission
replace=all. There's no way as I know to ensure that a
replacement terminates the current XForms processor. In cases where
that could happen are a replace=all which returns but
the current document isn't replaced. Another is where the browser
opens the document in a different window, in which case the same
thing can happen. So it seems that replace=all doesn't
always require replacing the current page; there are cases where it
doesn't happen. That was the argument against adding a new replace
value such as replace="new". We're stuck with the name replace.
That's one reason I wasn't in favor of adding a new value of the
attribute replace, since it already does behave like the proposed
new.
Steven Pemberton: Our spec requires
things on replace=all that aren't possible.
Nick van: The spec is updated already
and doesn't; it says MAY.
Erik Bruchez: In view of current
implementations with replace=all, the spec require you
to replace (shutdown?) the current processor but clearly there are
places where that's not going to happen. So the spec needs to be
changed. We have revised, as Nick points out, cases where the
processor is shut down and that implementations may not have to
dispatch xforms-submit-done or xforms-submit-error events.
Steven Pemberton: From your summary, I
gather that you think we don't have to change anything.
Erik Bruchez: I think part of the
discussion started when Joern asked for a new target attribute on
submission, target="_blank" or window ID. Someone said that it
would change the behavior of replace=all because it
doesn't replace the current document, and so we needed
replace="new" but since we already have cases where
replace=all doesn't replace the current document, we
don't need replace="new".
Steven Pemberton: So you're saying we
don't have to worry; the word "replace" isn't right.
Steven Pemberton: So, can we leave it
as it is?
Leigh Klotz: What about the new
thing?
Steven Pemberton: That's the target
attribute.
Leigh Klotz: Is that done?
Nick van: It's in the wiki: http://www.w3.org/MarkUp/Forms/wiki/Submission_Embedding
we use @replace=all
Steven Pemberton: Then we're good to
go, hearing no objections...
Erik Bruchez: Should we clarify the
spec to say that replace=all doesn't replace all
always. http://www.w3.org/TR/xforms11/#submit-evt-submit
Erik Bruchez:
when the value of the replace attribute on element submission is "all", the event xforms-submit-done may be dispatched with appropriate context information, and submit processing concludes with entire containing document being replaced with the returned body
Resolution 2010-06-9.1: For http://www.w3.org/MarkUp/Forms/wiki/Submission_Embedding we use @replace="all" with @target on submission rather than making up a new @replace value.
Action 2010-06-9.3: Erik Bruchez to update http://www.w3.org/MarkUp/Forms/wiki/Submission_Embedding with notes about when replace="all" doesn't.
Steven Pemberton: So what's the
result when you delete a node? I think you have to define that it's
the first of those, you make a copy.
Nick van: John had trouble with that,
in XPath 1.0 because those nodes aren't rooted in a document any
more, or in a different document. But we already have functions
that return nodes from different documents so I'm not sure that's a
problem.
Leigh Klotz: The instance
function.
Erik Bruchez: What is the problem? I
don't think we've resolved what happens with iterate when you
delete the current node or a subsequent node.
Leigh Klotz: John said that if an
action deletes its context node, the actions continue but any ones
that refer to the context node have no effect. This leaves only
setfocus. I ran into this with the following use case: delete a
node locally if it has a uniqid or delete it via submission if it
does. Now you have an action which is sure to delete its own
context node and then try to refer to the node later, via @if:
<action ev:event="DOMActivate"<<delete if="uniqid = ''' .../<<send if="uniqid != ''"/<</action<
<action context="event(submission-body)">...</action>
Steven Pemberton: What is our
conclusion? That it's not a problem?
Alain Couthuries: It might be a
problem for XSLTForms.
Leigh Klotz: Operating on deleted
nodes in XSLTForms produces errors, at least in the version which
doesn't use native XML.
Alain Couthuries: It might
change.
Leigh Klotz: I think we need to poll
John for consensus since everyone else seems.
Steven Pemberton: Please vote for
this: http://www.w3.org/2002/09/wbs/33280/xhtmlmod2010/
Steven Pemberton: We may use this for
XForms 1.2 Modularization.