Re: xforms-submit-serialize receives an empty value

Hi Mark,

I think you may have accidentally selected the old members-only mail 
archive for this, and I just noticed it didn't hit the public list.

So part of the point of this email is to raise awareness of it, and the 
other part is to respond.

The xforms-submit-serialize event doesn't contain the data serialization 
because the intent was to give host document processors a way to create an 
alternate serialization, not necessarily to embellish the data 
serialization.  The feeling was that if someone did want to embellish the 
data serialization, then they could create it for themselves by accessing 
the data instance and the relevant MIPs.

Its a bit debatable how easy it would be if we provided the data 
serialization in the submission-body property of the event since most real 
efforts to embellish the data would involve parsing the string, making DOM 
manipulations and serializing the result anyway. 

Some simple embellishments could be easier, but the feeling was that the 
overload of serialization would be drastic enough in most cases that 
creating the data serialization would just be wasted CPU cycles and 
memory. So, the way the text is written now, you don't have to do the data 
serialization if an event handler has provided an alternative.

Not saying we shouldn't provide this capability, but perhaps as a future 
feature that can be turned on somehow.  At the least, there was intention 
in the way it is written now.

Cheers,
John M. Boyer, Ph.D.
STSM, Interactive Documents and Web 2.0 Applications
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw





From:
"Mark Birbeck" <mark.birbeck@webbackplane.com>
To:
w3c-forms@w3.org
Date:
11/16/2008 05:07 AM
Subject:
xforms-submit-serialize receives an empty value




Hello all,

I've just been doing a code review on some changes to the Ubiquity
XForms processor, which implement the 'xforms-submit-serialize' event.
It prompted me to look at the spec again, and I have discovered that
what we have in the spec is not what I thought we were going to have.
:)

I'm flagging it up here because it might be worthy of an erratum, if
people agree with the alternative.

The way that things stand at the moment in XForms 1.1, is that an
event handler for the 'xforms-submit-serialize' event receives an
empty node into which it can add data. This data is then used to
*replace* the default submission data.

However, when we initially discussed the serialisation event, it was
meant to be a notification that the serialisation had been carried
out, and any handler would now get to 'see' that data.

By having access to the 'real' data that is about to be transferred
over the wire, the event handler gets the opportunity to make
modifications to the data before it's transmitted, but it also gets
the chance to use the data itself to make decisions. For example, an
address node might simply contain 'home' or 'office':

  <address type="home" />

and then the 'real' address could be inserted into the data during the
serialisation sequence.

This kind of thing is quite tricky in ordinary XForms, because to
achieve it you either have to modify the original instance and use
relevance, which then makes submission tricky. Or you need to have an
extra instance and move things around yourself. Using serialisation
event handlers is ideal, because in effect you are getting the extra
instance that you can modify, but without having to create and name
one yourself.

Anyway, I realise that prose has probably been in the spec for a
while, but I still think it's worth flagging up, since this small
change would make the serialisation notifications much more useful.

Regards,

Mark

-- 
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)