Steven Pemberton, CWI/W3C (chair)
Charlie Wiecha, IBM
Erik Bruchez, Orbeon
Leigh Klotz, Xerox (minutes)
Uli Lissé, Dreamlabs
Nick van den Bleeken, (Inventive Designers) [joined late]
Steven Pemberton: US Library of
Congress and eXist:
http://www.digitalpreservation.gov/news/2010/20100219news_article_mn_meeting.html
Leigh Klotz: It might be Dan
McCreary.
Erik Bruchez: eXist is also use din
http://history.state.gov/
Steven Pemberton: I added the test
suite to the agenda.
Erik Bruchez: I added a map
link.
Charlie Wiecha: The Hotel Sonesta is
nearby. I'll add some hotels to the list.
Action 2010-02-24.1: Charlie Wiecha to recommend hotels on http://www.w3.org/MarkUp/Forms/wiki/FtF_2010_03_24_Agenda
Steven Pemberton: Erik, what are
you goals?
Erik Bruchez: I'll finish my action
items on UI Events and I'd like to discuss that.
Erik Bruchez: There are some XForms
1.2 features that we had work started, but not completed, or
spec-ready text: XPath 2.0, Custom XPath Functions, Node Creations
Functions, Variables.
Erik Bruchez: We also discussed
components; is that for XForms 1.2?
Leigh Klotz: XBL?
Erik Bruchez: That would include XBL
if it was relevant.
Charlie Wiecha: Possibly not 1.2.
Steven Pemberton: Charlie?
Charlie Wiecha: Patterns such as
combinations of repeats and groups that roll up into master-detail;
or list-of-lists (contact list vs current list). There are
combinations that roll up into reusable functions. I don't know if
we want to consider that a 1.2 issue.
Steven Pemberton: Is that compatible
with the components discussion?
Charlie Wiecha: Components would be
one way to do it. I could imagine doing it without formal
components using an AJAX component model instead of XBL. We can
think about the patterns separately from their implementation
technology. I don't know if it's of interest to the group as a
whole to think about them. We might have some introductory
conversation to decide if we want to focus on it.
Steven Pemberton: Any any FtF, we
should try to cover things that people are interested in.
Charlie Wiecha: I'd also like to talk
about JSON serialization.
Steven Pemberton: Kenneth says his
version isn't 100% round-trippable.
Charlie Wiecha: Do we do full XML with
an arbitrary content model, or a more data-centric version?
Charlie Wiecha: Also, I have work item
for external models with @src, and I'll try to have that text
done.
Steven Pemberton: Uli?
Uli Lissé: I'm not going to be
able to attend.
Steven Pemberton: You can join
remotely.
Uli Lissé: I'm especially keen
to get the UI events done.
Steven Pemberton: Charlie, we'll
need a conference phone.
Nick van: [joins]
Steven Pemberton: Leigh?
Leigh Klotz: The topic I'm most
interested in in XForms for HTML:
Steven Pemberton: The documetn?
Leigh Klotz: What exactly we're going
to do and how we're going to do it.
Steven Pemberton: We're going to do it
as a note?
Leigh Klotz: That surprised me because
it was a rec-track document before.
Steven Pemberton: In a note, we can
describe how it's working now and we don't need last call.
Leigh Klotz: If it seems opportune I'd
like to move it back to REC track.
Steven Pemberton: Anything else?
Leigh Klotz: I'd like to see the
component discussion; I think components in XBL or JavaScript can
be done without us, or at least if we remove any disablers. Charlie
has mentioned these two approaches, and I can see JS and
server-side transformation implementations using these approaches
as well. People manage to get HTML integration done, and we may
just need to figure out if we're blocking component
integration.
Steven Pemberton: Anything
else?
Charlie Wiecha: Dinner!
Steven Pemberton: Member voting is ongoing.
Steven Pemberton: We did some
changes last time. Any reports?
Nick van: I will publish the new
list.
Steven Pemberton: This is the
question of live instances; I have always thought this is a central
issue for us, perhaps for XForms 2. JavaScript allows you to change
a p/@class on a document; it would be good if XForms 2 could do
that for you. If the document were linked to the form, that would
give more power to XForms.
Nick van: There are implementations
that do that.
Erik Bruchez: We do this with AVTs. I
know there problems in HTML attributes. We use an
xxforms:attribute/@for which points to the HTML element, its
attribute, and the attribute value. We use this all the time to
modify class and style elements.
Leigh Klotz: Is that an action or a
binding?
Erik Bruchez: It's a control with a
value attribute. It's not a binding because it's an AVT.
Leigh Klotz: Does it change when the
instance changes, or do you have to send an action to it?
Erik Bruchez: It's like an
output.
Leigh Klotz: So it's done on
refresh.
Erik Bruchez: It's done on
refresh.
Steven Pemberton: There are two
solutions?
Erik Bruchez: The second is that you
can use this directly instead of through the AVT. It would be
xf:attribute. So that's two solutions by syntax, but we just use
the xxforms:attribute when we see AVTs on XHTML controls.
Steven Pemberton: I've also considered
an instance which represents the current document, like self.
Nick van: Then you have to set values
and calculates. AVT is more powerful.
Erik Bruchez: <div class="foo
instance('my-instance')/my-classes
bar">
Nick van: It's more intuitive and
declarative than using @calculate.
Steven Pemberton: We do have a
problem that this creates invalid HTML, because the
thing-being-validated aren't the values that match the declared
datatype of the thing.
Erik Bruchez: It depends on how you
look at it; if it ends up in an HTML DOM, maybe, but if it's a
pre-processing step (as we do) it's OK.
Steven Pemberton: I agree that it
should be OK. Some government departments require that their HTML
validates; you'd have to have a different schema.
Erik Bruchez: This is actually easy to
solve because you can define the element xxf:attribute to be the
canonical construct; for implementations that support AVT in the
host language then you can do it this way. Implementors might be
free to support it or not. For author convenience, author
convenience is the kin. It minimizes keystrokes.
Leigh Klotz: You could consider it an
authoring convenience and then run an XSLT and then validate the
result in multiple namespaces, for those who need to validate XHTML
in its namespace.
Erik Bruchez: This only addresses
changing attribute values, not adding or deleting them.
Leigh Klotz: This is a great example
of the type of thing that could be written up as a module.
Erik Bruchez: While we're at it we
could move xf:range to a separate module.
Steven Pemberton: I've added Live
Documents to the agenda for the FtF.
Steven Pemberton: For today, this isn't really about xforms-ready. I think the list answer is OK, because there is an example. Does anyone disagree?
Leigh Klotz: This breaks the back
button, and the URL looking as it should, etc.
Erik Bruchez: There are hacks to fix
the back button and the anchor. You'd have to store it somewhere.
It might not be a sure problem because of local storage
facilities.
Leigh Klotz: It's not a question of
implementation, but of what we want. load/@replace='all' leaves the
old page behind. Why do implementations want to keep the page in
place for submission/@replace='all'.
Erik Bruchez: I think we made a change
to XForms 1.1 to allow the events not to be dispatched.
Steven Pemberton: You're not
guaranteed to work if the mediatype isn't HTML; what if it's
PDF?
Erik Bruchez: We called this the
optimized get-all. We just send it to the server. There are cases
where you can't do this; in particular, the case where you specify
an xforms:header child element.
Leigh Klotz: Nor can do you it with
POST, but it should work on GET.
Erik Bruchez: The most common case
with xf:replace='all' is equivalent to loading the URL in the
browser, like an xf:load. You still have the problem using the POST
of XML through XHR?
Leigh Klotz: There is a hack Alain
proposed serializing XML in POST of
application/x-www-urlencoded.
Leigh Klotz: Do we think that's what
people want?
Steven Pemberton: My expectation is
that people want just what the browser did.
Nick van: But the JS versions can't do
that with XML submit.
Erik Bruchez: XForms 1.1 says "For a
success response including a body, when the value of the replace
attribute on element submission is "all", the event
xforms-submit-done may be dispatched."
Leigh Klotz: I think preserving the
expected user-agent behavior is more important than these
events.
Steven Pemberton: Agreed.
Erik Bruchez: XForms 1.1 is specified
as if the XForms processor has full control over the user agent. We
did make this change for that, but it still looks like it's
something that's meant to be native. For users, a JS or server-side
implementation with a POST of an XML document the URL in the
browser is something different. It seems unavoidable because you
can't modify the URL beyond the fragment. The other things with
xf:submission go through XHR or the server-side component. It's a
little un-natural but workable. Are we happy to keep the spec that
way or should it reflect the browser world?
Nick van: For me it's not a big
problem because the spec already permits it. It would be more
natural that if you had full control XML submit would nicely
replace the URL, but if it isn't possible I don't think we need to
re-write our spec for the limitations in JS.
Leigh Klotz: It's possible to make it
work with GET, and there are ways it could .
Nick van: Not for cross-domain.
Steven Pemberton: What's the
conclusion?
Leigh Klotz: Are
submission/@replace='all' and load/@show='replace' different?
Nick van: The events could be
different. You are permitted by the spec. Preferably you could the
events.
Leigh Klotz: So you get a choice
between user agent behavior and the events, but Erik points out you
may be able to get the back button to work via a hack.
Nick van: Isn't it up to the
implementation?
Steven Pemberton: In a spec, we want
to assure interoperable behavior, and make sure things work the way
they "ought" to work. Maybe that's the same thing. If we say it's
an implementor's choice, it seems like you could never be sure. It
might discourage you from using XForms. For example, I have a bank
where the back button doesn't work; they log you out. It's in
muscle memory and I'm constantly logged out, and it drives my
potty.
Erik Bruchez: The back-button issue is
fixable; it's a quality-of-implementation issue. Your bank has done
it wrong; there are countless ones that don't handle the back
button. A good framework or a good implementation of client-side JS
has the ability to handle the back button.
Erik Bruchez: As far as submission is
concerned, we are constrained by what the browsers allow you to do.
As soon as you go by GET or HTML4 form POST, you have to do
something slightly unnatural in the browser; either you use
fragments or POST to a server-side component. Until browsers allow
you to POST XML and support the serializations we support in XForms
submission, we can't.
Leigh Klotz: This implementor's choice
has been to break the page even on the simple cases for GET and
HTML4 POST.
Steven Pemberton: I think Leigh is
right; the page is more important and we should make it
clearer.
Erik Bruchez: Maybe the "MAY" isn't
clearer in the spec. We made the change exactly for this reason, or
John might remember.
Steven Pemberton: Conclusion or
more discussion? If we agree that the events are optional, we
should just say that.
Nick van: We do say that. You don't
even have to have a good reason not to. It's a MAY. We made it
clear.
Resolution 2010-02-24.1: Dispatching xforms-submit-done and xforms-submit-error after submission/@replace='all' is optional and is not as important as other considerations, such as conforming to non-XForms user agent requirements of showing the page's URI and back button. While some non-native (JavaScript and server-side) XForms+XHTML implementations have been able to use techniques to retain most of these advantages in the complex cases of POST with application/xml serialization, we still see it as more important to conform to greater user-agent expectations in easier cases, such as <submission method='get' replace='all'>.