cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <>
Subject Re: Flow and XMLForm
Date Tue, 21 May 2002 03:03:30 GMT
On Mon, 20 May 2002 14:02:30 -0700, wrote:

> Ovidiu,
> <snip />
> > - why do you need XMLForm when you have flow control? You can do the
> > same things XMLForm does in the flow layer.
> > ;)
> > Now seriously, I think there's a lot of overlap between the two
> > implementations right now.
> > What I think we need is a way to describe, using Schematron, just as
> > in XMLForm, the relationships between elements of the XML instance
> > document. A stylesheet could then generate the JavaScript validation
> > scripts, a set for the client browser, and another one for the server,
> > very similar to the one for the client. The flow between pages can
> > then be implemented using flow scripts.
> > In the above approach, I'm obviously biased towards the flow layer, so
> > I'd appreciate some more thoughts on it. What I'd also like to see is
> > a way to reuse most of Ivelin's work, as I don't have much experience
> > with it.
> Are suggesting that the flow layer with the addition of some kind of
> Schematron processor could completely replace XMLForm?  And if so, could
> you elaborate why you think this would be a better solution?

With respect to the ability to handle user input for editing an XML
document, if you look at the functionality provided by the two, they
are very similar. Nothing prevents implementing an XMLForm-like
processor on top of the control flow engine. Whether this would be
better I don't know, I can't say anything until such a thing is
implemented. I was just observing that the overlap between the two

> Also, are you thinking of something like Rhino on the server so that
> validation could be done by similar javascript on both client/server?

Yes, the current control flow layer uses a modified version of Rhino
on the server side. It should be possible to write the validation code
directly in JavaScript, and have it run both on the server and on the
client browser.

JavaScript client validation improves the user experience quite a bit,
so I think a validation solution should generate both client and
server side validation code.

> Finally, I think transforming Schematron to javascript could be very tricky.
> Something like <assert test=".!=''"> might be easy enough to transform,
> or even <assert test="/NAME_PREFER!=/NAME_ALIAS_FIRST">, but what about
> <assert test="not(contains(translate(.,'!@#$%^&amp;*()_+-=0123456789','
> ************************'),'*'))">
> The nasty problem here is that the "conditional" part of an assert
> is unparsed character data, not xml markup, and so (almost) impossible
> to transform.  Seems like you would need to use a constraint description
> language that expresses more of its content in "pure" XML (perhaps XMLSchema??).
> Or perhaps some even more abstract XML "model/constraint expression syntax"
> which could be translated into XMLSchema, Schematron, or client/server
> javascript as needed, i.e:
>       <validation-rule>
>             <validation-test>
>                   <instance-node name="LAST_NAME" type="String" />
>                   <contains>!@#$%^&amp;*()_+=0123456789</contains>
>             </validation-test>
>             <message>Last Name contains an illegal character.</message>
>       </validation-rule>
> (A very crude example, but you get the idea...)

Yes, this is what I had in mind. You're right, transforming a
Schematron document in JavaScript could be a difficult task. A
constraint language as you describe above would be better, since
writing a translator to JavaScript is much easier. However the
expressiveness of such a language is lower than that of an XPath-based

So there are three ways an XMLForm-like capability could be

- translate today's XPath-based Schematron to JavaScript scripts for
both client and server side

- translate a constraint expression syntax, not based on XPath, to
JavaScript for client and server side

- write the validation functions in JavaScript, same scripts being
used on the server and client side.

I don't know about you, but the last approach looks to me being the
easiest one to implement (basically write your scripts). One problem I
see with it though is ties the validation to JavaScript, making it
difficult to support clients that don't run JavaScript, like browsers
on WML phones (although the language used is very similar).

Ovidiu Predescu <>

>>> I'm in the job market again, check out my resume and qualifications at: (GNU, Emacs, other stuff)

To unsubscribe, e-mail:
For additional commands, email:

View raw message