cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <ba...@webslingerZ.com>
Subject Re: XInclude Processor should be fixed now
Date Mon, 05 Jun 2000 19:15:53 GMT
On Mon, 5 Jun 2000, Daniel Schneider wrote:

> > On Sat, 3 Jun 2000, Daniel Schneider wrote:
> > 
> > > > On Fri, 2 Jun 2000, Daniel Schneider wrote:
> > > >
>   .......
> > >     // (3) then catch the special node
> > >     //  loop
> > >         node = children.item(i)
> > >         int type = node.getNodeType();
> > >         switch ( type ) {
> > >         case Node.DOCUMENT_TYPE_NODE: {
> > >         // NOW KILL THE THING :)
> > >         doc.removeChild(node);
> > >     // exit loop
> > 
> > You sure got the right idea. I just checked in a patch based on this,
> > check it out and see if it helps your problem.
> > 
> Hi thanx a lot for looking into this, ..... but no, it does not help :(
> 
> In my uneducated guess there is a problem with the parser. I don't
> have any clue what that might be. I looked at
> org.apache.cocoon.parser.XercesParser and its code does not seem to
> ask for any validation entailing that the external DTD must be read
> (Anyhow the question WHY xerces can not find a simple relative DTD
> declaration remains is another thing to look at ....)
> 
> I diversified a bit your error catching and sent messages to the log file.
> So basically the thing breaks BEFORE your stripDocumentTypeNodes fix:
> 
> [05/06/2000 20:37:52:046 CEST] +++ processXIncludeElement +++ SAX exception found
> [05/06/2000 20:37:52:047 CEST] File "file:/hello.dtd" not found. [FATAL ERROR] [File:
> "null" Line: -1 Column: -1]
> [05/06/2000 20:37:52:047 CEST] *** Other exception found:
> java.lang.NullPointerException
> 
> Code snippet:
> 
> try {
> 	    included_document = parser.parse(input,false);
> 	    stripDocumentTypeNodes(included_document.getDocumentElement());
> 	    // stripDocumentTypeNodes(included_document);
> 	}
> 	catch (SAXParseException e) { 
> 	    logger.log("+++ processXIncludeElement +++ The File is not well formed.", 1);
> 	    logger.log(e.getMessage()
> 		       + " at line " + e.getLineNumber() 
> 		       + ", column " + e.getColumnNumber(), 1);
> 	}
> 	catch (SAXException e) { 
> 	    logger.log("+++ processXIncludeElement +++ SAX exception found", 1);
> 	    logger.log(e.getMessage(), 1);
> 	    // e.printStackTrace(logger);
> 	}
>         .... and so  forth
> 
> If I am right you can't do anything about this and I don't know who's problem
> this might be. Just in case Stefano is listening in: My  main 
> motivation for wanting xincluded files to have DTD declarations is that I believe
> that even "sloppy" Web sites have to make sure that XML is somewhat valid .. but
> unfourtunately it is difficult for some persons to remember removing the DTD,
> especically if the WWW tree is mounted on all local file systems 
> (got empirical proof for that)... and finally the tools we are using can't
> read DTDs over HTTP (so absolute URLs are out too).

Actually, I reckon that if I called setSystemId on the InputSource I'm
passing to Xerces, it should be able to resolve the relative link to the
DTD with no trouble. Question is, what parameter to I use when calling
setSystemId...? Anyone have a clue for me?

- donald


Mime
View raw message