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=8711>.
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=8711

Better control over validation

           Summary: Better control over validation
           Product: XalanJ2
           Version: CurrentCVS
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: org.apache.xml.dtm
        AssignedTo: [EMAIL PROTECTED]
        ReportedBy: [EMAIL PROTECTED]


Currently, Xalan doesn't give us much control over when input documents are
validated; to take control, one has to instantiate a parser and pass in a
SAXSource rather than letting Xalan create the parser instance itself.

And the current state of the world is a bit confused; I think incremental vs.
non-incremental, and Xerces versus other parsers, may affect whether validation
occurs or not.

We should provide a better set of controls for whether DTD and/or schema
validation is performed. We did, long ago -- see the commented-out -VALIDATION 
switch in Process.java -- but that was dropped, probably because the XSLT data 
model requres some info which may only be available after DTD validation. There 
might still be an argument for allowing DTD validation to be turned off in 
special cases.

(Note: For performance reasons, I do _not_ currently recommend we default
to schema validation being turned on. As Xerces improves the speed of their
schema validator, we can reconsider that default.)

(Also note: Turning off DTD validation may _NOT_ prevent an external subset from 
being fetched. Setting the standalone flag in the document, ditto. The standard 
workaround if someone Really Doesn't Want that retrieval to occur is to plug in 
an EntityResolver that recognizes this request and returns an empty entity. 
There are quibbles about how that recognition is performed, but it might be nice 
if we included such a resolver as a canned tool, so Process to be told to use 
it. On the other hand, it's unclear that this one is a Xalan issue rather than a 
Xerces issue.)

Reply via email to