On Mon, 20 May 2002 14:02:30 -0700, [EMAIL PROTECTED] 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 things. > 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(.,'!@#$%^&*()_+-=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>!@#$%^&*()_+=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 description. So there are three ways an XMLForm-like capability could be implemented: - 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). Cheers, -- Ovidiu Predescu <[EMAIL PROTECTED]> >>> I'm in the job market again, check out my resume and qualifications at: http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
