cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@dff.st>
Subject Re: Flow and XMLForm [LONG]
Date Wed, 22 May 2002 23:55:40 GMT
On Wednesday 22 May 2002 23:32, mratliff@collegenet.com wrote:
> Torsten,
>
> I guess it depends on what one means by constraint.  XForms allows
> constraint dependency rules described using XPath.  So if you have two
> fields, "CLASS_RANK" and
> "CLASS_SIZE"  you can (I think) write a rule that says "value of CLASS_RANK
> must be less than or equal to CLASS_SIZE", i.e, something like:
>       <xforms:bind ref="instance/CLASS_RANK" isValid="current()
> <= ../instance/CLASS_SIZE" />

Michael, I am aware that there are more complicated dependencies possible than 
that... but since I have not really had a use-case yet... maybe you could 
send me an example of what you would like to express - no matter in which 
schema. This could maybe help both of us...

If you consider this too delicate we could talk off the list first and present 
an abstract summary to the list later ...a as you like.


> But even if you have such an XPath expression, it's just text to a parser--
> nothing to
> parse.  And so, very difficult to translate into javascript.  If instead
> you have a regex constraint
> you don't need to parse it, just drop the string into a javascript object
> and create the handlers
> that call the right method..

True.

The idea was to ask the constraints for a JavaScript representation... so if a 
constraint implement e.g. JavaScriptable (something like that) we can insert 
that with a transformer right into the stream. Question is if we can express 
all different kinds of dependencies this way. I'm looking forward for you 
example...

> Anyway, I need to handle forms that have much more complicated dependencies
> than the simple CLASS_SIZE/CLASS_RANK example given.  Such dependencies
> are easy to "describe" in javascript,  difficult to describe in
> XPath/Schematron.

well, but not very "manageable". Using javascript it becomes more like - do 
everything by hand...

> So now I'm thinking about some kind of  "ur-language" for describing
> dependency (and other?) relationships, abstract enough to be translateable
> into Schematron rule markup, javascript procedural code, or whatever else
> is needed.

yes... I'm also thinking of something like that... Some people go crazy if 
it's not standard - but why not invent a new standard ;-)
...as long as it's not just reinventing the wheel...

although I'd like to have support for relaxng, xsd and schematron for the form 
handling stuff I also considered inventing something new (for our company in 
the first place) since all current schemas I know of are lacking something... 
Why not try to solve that...

Your are welcome to help ;-)
--
Torsten

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


Mime
View raw message