> I apologize for not crediting you properly. I meant the people discussing it on the list... not just me :-)
<snip/> > > Well, actually my idea was to define validation more expressive so we can > > even > > > > generate client side javascript validations! This should work quite easy > > if you look at the precept example. I see the problem in a different > > area: schematron - all you have are XPathExpression constraints. Easy to > > come up with, but - you only know that a specific XPathExpression failed. > > This doesn't give useful information for clientside validation. If you > > had different type of constraints e.g. a regular expression constraint > > that failed this could be easily translated it into javascript by a > > stylesheet. > > Regex constraints are more flexible because you can pass the regex string > to client javascript for evaluation? What about non regex constraints? the idea is to have all different kinds of constraints. the most ovious ones are probably: - regexpr - min length - max length - min value - max value ...just to give you an idea. since those constraint can quite easiyl be translate into javascript. so if your validation schema supports a bit more than just right or wrong (like an xpath expression is) you will be able to have client side pre-processing and server-side double checking ;-) > I still need rule based constraints as in Schematron, but they need to > be represented in a way which can be translated into javascript (i.e. not > as non-parsed character data in the "test" attribute.) you mean constraints that depend on some circumstances (nodes ...)? ...that's in the first place again a question of the validation schema - not of the framework. > I plan to take another, closer look at Precept when I have finished my > excercises > with XMLForm. ...feel free to contact me directly for questions cheers -- Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
