Christian Haul wrote:
> To me, XForms looks like the most importand standard on this but I
> think it is not advisable to aim for a fully compliant implementation
> for C2 because (please correct any errors)
>
> a) XForms expects XML encoded parameters. I'm not 100% sure on
> this, but I think few to none of the available browsers
> support this. I don't think it would make sense to convert
> request parameters to a XML representation before processing
> them since this would probably be too costly. A Javascript
> solution to post parameters as XML is propably out of the
> question.
There are three information types:
application/x-www-form-urlencoded
multipart/form-data
text/xml
If the submission type is not "text/xml" (like from a SOAP request),
then the submission form parameters match the simplified XPath to
their position in the document:
XML-Instance we want:
<user>
<name>Berin Loritsch</name>
<email>bloritschATapacheDOTorf</email>
</user>
Our Form:
<text name="/user/name"/>
<text name="/user/email"/>
Which means that for the two standard submission types (url encoded
and multipart), the XPath expression is used to reconstruct the XML
document.
> b) XForms allow besides the basic types arbitrary types definable
> in XML Schema. While this might be possible for validation, it
> is expensive but seems only necessary if parameters are XML
> encoded.
Once you have your XML recreated (from an XML reconstructor Action),
you should be able to apply them any way. It is expensive, so the
benefits have to be weighed carefully.
> c) XForms declare forms within the <HEAD/> section of a
> document. XSP don't have such a concept.
This is a markup issue. Basically, the instance/schema/binding info
is stored at the top of the document in an <xform> tag.
> d) XForms' forms can be mixed and nested. This is not possible
> with current XHTML forms.
This is true. There are two potential solutions:
1) only have one form for the whole document and separate the
markup and validation at server side.
2) force the user to use XHTML form constraints.
> e) XForms specify validation as XPath expressions. Makes only
> sense if form data is accessible through XPath.
In an XForms implementation this is a requirement. Validation is
done via Schema (current spec), as well as Dynamic Constraint Language
(based in part on ECMAscript).
References are by XPath.
> f) XForms specify active behaviour: triggers, conditionals
> ... This is probably out of scope.
This can only be in scope if you have a transformer that creates
Javascript on the fly. As different browsers have different methods
of referencing form parts, this is where the BrowserSelector can
come in handy.
Again, this is not easy.
> g) XForms provide sliders, subpages, lists &c. This is too complex
> for short term availability.
True.
> h) XForms specify subpages. Whiles this could be done it's also
> probably too complex for short term availability.
I would implement it as another "page" in the form. In other words, we
do validation on the information we have, and go to the subpage, etc.
> i) XForms don't specify error messages.
This is my biggest beef with it. They have heard this complaint before.
> j) Since validation is (at least additionally) server based, this
> should keep the already filled in elements.
XForms is largely a Client specification--which I also have issues with.
Some of it can be done server side, but things like DCL make it difficult.
> >From this follows, that a fully compliant implementation should not be
> the goal.
Agreed.
> To do would be (not necessarily in order of importance)
>
> 1) enhance form validator action to validate more XForms basic
> types.
XForms is now completely Schema based. Throw the generated XML through
Xerces and see what gets kicked out. I would implement the ErrorHandler
so that all errors can be cached.
> 2) provide a taglib that combines necessary features from
> formval.xsl and request.xsl plus some form specification that
> produces valid XForms
Your biggest issue is referencing existing information from the XML
instance and the XPath expression to get the information you need.
> 3) provide stylesheets that render HTML-4.0 forms (probably
> separate ones for IE, NS &c), XSL-FO &c.
I started on this a while ago. The overall style really depends on
the site. Bottom line is that XForms is a moving target.
> 4) provide javascript routines that do client side checking (as
> well for major platforms)
This really would have to be both platform and XForm specific. The
Javascript would need to be auto-generated.
S/MIME Cryptographic Signature
