Return-Path: 
 <cocoon-dev-return-27039-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 3755 invoked by uid 500); 20 May 2002 20:54:57 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 3744 invoked from network); 20 May 2002 20:54:57 -0000
Subject: Re: Flow and XMLForm
To: cocoon-dev@xml.apache.org
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OFD560C09E.EFB726F9-ON88256BBF.00712E99@collegenet.com>
From: mratliff@collegenet.com
Date: Mon, 20 May 2002 14:02:30 -0700
X-MIMETrack: Serialize by Router on pdx1/UAI(Release 5.0.9 |November 16,
 2001) at 05/20/2002
 02:02:24 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N


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?

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

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...)

Cheers,
--Michael


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org