Ivelin,
>>> >>Report is supported. Report is simply a negation of assert.
>>>
>>> Just double checked this again. Report doesn't work for me. This works:
>>> <assert test="contains(not(.,'$'))">
>>> but this doesn't:
>>> <report test="contains(.,'$')">
>>I've tested it a bit but maybe there is a bug. Feel free to save XMLForm
>>again :)
>>The implementation is one line, so I can't immediately see where the problem
>>might be.
>>> ><assert >cannot contain <myns:name/> </assert>
>>>
>>> This would be *great* !! But unfortunately, doesn't work for me. Thought
>>it
>>> might be because I my tags didn't have their own namespace so I tried:
>>> <assert test=".!=''">Please provide a <cnet:some_tag /></assert>
>>> but the <some_tag> element just gets stripped out (by the validation
>>> transformer?).
>>Strange. Not intentional. Maybe another bug that waits to be busted.
> I'll try to look into these problems this coming week...
I dug into the code to see what was going on. Here's what I found out...
1) <report> was definitely supported and definitely not working. The problem
was in the bindRules method of
org.apache.cocoon.validation.SchematronFactory.java where you create the
SchematronSchema object that gets processed by the Schematron Validator. You
call bindAsserts to add asserts to the SchematronSchema object, but never call
bindReports.
So all that nice code you wrote for handling <report> never gets called. Once I
fixed this little "buglet" everything
worked fine (and corrected spelling of "bindRerports" [sic] everything worked
fine. I have sent you a patched file...
2) The "elements inside <assert> getting stripped out" problem was more
confusing. Here's how you appear to be getting the contents of <assert> or
<report>:
String message = (String) jxpContext.getValue ( assertPrefix, String.class
);
report.setMessage( message );
Since you are getting a *string* here I don't see how your code could possibly
handle elements. Also, all of your "downstream" code for handling the
assert/report "message" assumes type string, so AFAIK you would have to change
most of the Schematron Validator to support passing elements through to the xslt
processor. Have I missed something?
3) Incidentally, I think somebody *could* modify XMLForm to support Schematron's
<name/> and <value-of/> elements. If I understand jxpath, you could get a
jxpContext for the appropriate view and then call getValue with the proper xpath
parameter. The result would be a string which *could* be handled by the
"downstream" code already in place. Not high on my priority list: I need #2
more than #3. Any other takers?
Cheers,
--Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
