Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 95727 invoked from network); 8 Oct 2003 11:52:08 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 8 Oct 2003 11:52:07 -0000 Received: (qmail 23654 invoked by uid 500); 8 Oct 2003 11:52:01 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 23606 invoked by uid 500); 8 Oct 2003 11:52:01 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 23592 invoked from network); 8 Oct 2003 11:52:00 -0000 Received: from unknown (HELO exchange.sun.com) (192.18.33.10) by daedalus.apache.org with SMTP; 8 Oct 2003 11:52:00 -0000 Received: (qmail 20285 invoked by uid 50); 8 Oct 2003 11:55:03 -0000 Date: 8 Oct 2003 11:55:03 -0000 Message-ID: <20031008115503.20284.qmail@nagoya.betaversion.org> From: bugzilla@apache.org To: dev@cocoon.apache.org Cc: Subject: DO NOT REPLY [Bug 6200] - Parser failure with validate=true when processing stylesheet X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . 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=6200 Parser failure with validate=true when processing stylesheet ------- Additional Comments From bruno@outerthought.org 2003-10-08 11:55 ------- Configuring the xml-parser component with validate=true will never work, simply because this is the parser used to parse every single XML file. This means also XSLT stylesheets, JXTemplate files, Woody form definition, or any arbitrary XML markup. We can't possible have DTD's for all these formats, and can't require the DOCTYPE to be present everywhere. What would be needed in my opinion is a ComponentManager where we can explicitely resolve the dependencies. So you would then be able to configure multiple instances of the xml-parser and let one filegenerator use a validating parser and let another one use a nonvalidating parser. Something similar is currently done for the store component: there are multiple stores and for some components you can explicitely configure which store role they should use. We could do the same thing for the xml-parser, i.e. make a "parser/validating" role and a "parser/nonvalidating" role and make it possible for relevant components (mostly the FileGenerator I think) to configure which role they should use. However this seems like an abuse of the role concept, I'd rather have a component system where the dependencies can be explicitely provided (I know this is possible in the Phoenix container, not in ECM, don't know about the others).