On Thu, 7 Mar 2002, Nicola Ken Barozzi wrote:
> > tried to figure out how to disable validation to ignore
> > the issue completely. well, it seems that in c2.0.0, you cannot configure
> > the parser's validation behavior in the cocoon.xconf file. i looked in the
> > source for JaxpParser, and was surprised to note the parser factory's are
> > configured to create non-validating parsers:
> >
> > public JaxpParser ()
> > throws SAXException, ParserConfigurationException {
> > this.factory.setNamespaceAware(true);
> > this.factory.setValidating(false);
> > this.docfactory.setNamespaceAware(true);
> > this.docfactory.setValidating(false);
> > }
> >
> > if this is right, why is the parser trying to validate?
>
> Hi Donald! :-)
hey yourself :)
> When a DTD is declared, it is needed by the parser even if it's not
> validating.
> Take for example how it parses whitespaces: if an element is declared in the
> DTD to contain only other elements, the whitespace between itself and the
> children is not sent; otherwise it is, since the parser doesn't know if it
> is needed (has a meaning) or not.
okay, guess i gotta figure out why it can't resolve the DTD then. fwiw,
the problem also occurs in the latest cvs build of c2. the stacktraces i
get are:
org.apache.cocoon.ProcessingException: Exception during processing of
http://www.ncbi.nlm.nih.gov/entrez/utils/pmqty.fcgi?db=PubMed&mode=XML&dispmax=999&term=Smith[au]:
java.net.MalformedURLException: no protocol:
/entrez/query/DTD/pmqty_020122.dtd
at
org.apache.cocoon.components.source.AbstractStreamSource.toSAX(AbstractStreamSource.java:209)
at
org.apache.cocoon.generation.FileGenerator.generate(FileGenerator.java:142)
more to the point:
java.net.MalformedURLException: no protocol:
/entrez/query/DTD/pmqty_020122.dtd
at java.net.URL.(URL.java:473)
at java.net.URL.(URL.java:376)
at java.net.URL.(URL.java:330)
at
org.apache.xerces.impl.XMLEntityManager.startEntity(XMLEntityManager.java:731)
at
org.apache.xerces.impl.XMLEntityManager.startDTDEntity(XMLEntityManager.java:691)
at
org.apache.xerces.impl.XMLDTDScannerImpl.setInputSource(XMLDTDScannerImpl.java:258)
at
org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(XMLDocumentScannerImpl.java:811)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:333)
at
org.apache.xerces.parsers.StandardParserConfiguration.parse(StandardParserConfiguration.java:525)
at
org.apache.xerces.parsers.StandardParserConfiguration.parse(StandardParserConfiguration.java:581)
at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:147)
at
org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1157)
at
org.apache.avalon.excalibur.xml.JaxpParser.parse(JaxpParser.java:241)
at
org.apache.cocoon.components.source.AbstractStreamSource.toSAX(AbstractStreamSource.java:204)
at
org.apache.cocoon.generation.FileGenerator.generate(FileGenerator.java:142)
the document header looks alright to me:
<?xml version="1.0"?>
<!DOCTYPE QueryResult PUBLIC "-//NLM//DTD QueryResult, 22 Jan 2002//EN"
"/entrez/query/DTD/pmqty_020122.dtd" >
i interpret that to mean the DTD is located at path "/entrez..." from the
root of the space from which the xml document was retrieved - namely,
http://www.ncbi.nlm.nih.gov/. is the document header invalid for some
reason i'm missing, or is one of the resolver components not working as it
ought?
- donald
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
