You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by bu...@apache.org on 2003/04/17 11:31:39 UTC

DO NOT REPLY [Bug 19104] New: - SchematronValidator incorrectly creates JXPath contexts which breaks tests in schemas

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19104>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19104

SchematronValidator incorrectly creates JXPath contexts which breaks tests in schemas

           Summary: SchematronValidator incorrectly creates JXPath contexts
                    which breaks tests in schemas
           Product: Cocoon 2
           Version: Current CVS 2.1
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: general components
        AssignedTo: cocoon-dev@xml.apache.org
        ReportedBy: johan@hippo.nl


Currently in Schematron schemas it is not possible to use the parent context in 
tests of a rule. Because of this it is not possible to make inter-element tests 
and have the violations assigned to a specific element.

For example:
/newLogin/password
/newLogin/repeatedPassword

If the repeated password does not match a violation should be added.
<rule context="/newLogin/repeatedPassword">
    <assert test="string(.) = string(../password)">Passwords must be the 
same</assert>
</rule>

Should result in the following violation:
path = /newLogin/repeatedPassword
message = Passwords must be the same

The problem is in the 'evalRule' method of the 'SchematronValidator' class. To 
create the local JXPath context for this rule 'JXPathContext.newContext(...)' 
is used currently. If this statement is replaced 
with 'jxpContext.getRelativeContext(...)' the parent context can be used.

I do not know what the semantic differences between 'newContext' 
and 'getRelativeContext' are. I can not tell if this change would break 
something.

I will add a patch to this bug report.