two issues 1. xml parser bug
don't think this is a bug, but it might be a subtle spec-conformance issue after a little testing/reading it appears that if the "http://xml.org/sax/features/validation"; feature is set to true, an instance *must* have validity information - if there's no DOCTPYE at all, get "doctype name must equal 'null' " type errors - if i try <!DOCTYPE root-tag-name SYSTEM> i get "whitespace after system keyword" type errors - if i try <!DOCTYPE root-tag-name SYSTEM ""> i get "no protocol" type errors - same goes for the PUBLIC "" "" route as well i can't remember this from the spec but i'll re-read it and re-post if i find anything solid so i wrote a quick xsl script to generate a minimum dtd for a given xml instance (get round the poor ANY keyword), so that's one way round it - provide a minimum dtd for every xml file cocoon parses and keep patching each distro i may post the odd dtd/schema if i get round to making them tight - but i'd have to synch with cocoon-dev and if cocoon is intended to be non-validating then what's the point? 2. cocoon being "non-validating" sure xml parsers do the validation, but cocoon aloows them to be configured to validate then fails when that option is exercised - the <xml-parser> stuff in cocoon.xconf is global right? - thus if i want validated xml to be passed down a pipeline from a generator (file probably) my only option is to set this parameter isn't it? - or do i have to write a custom generator/xsp that configures a parser in java code manually? i'd rather validation was global, but this will do. it seems to defy the point of using avalon configuration though it also seems odd to provide a global validation flag, and then not provide validity information for all markup read by the xml parser if that flag is set to false (the only way cocoon runs without failure), then doctype retrieval is being done in non-validating mode just for entities, attrib defaults, etc and therefore cocoon is a non-validating process at heart, imho this may speed things up, but i like the idea of validation i don't see why i'm forced to turn it off we may have to agree to disagree on this one thanks for the help and bugzilla link Vadim Gritsenko wrote: >>From: Ian Atkin [mailto:[EMAIL PROTECTED]] >> >>using cocon v2.0.3 >> >>i've just changed the xml-parser validate parameter to true and cocoon >>failed with a "doctype name can't equal 'null'" error >> >>upon investigation the xml file concerned, treeprocessor-builtins.xml, >>doesn't have a doctype tag - which explains it >> >>is cocoon intended as a non-validating process for speed reasons? >> >> > >Cocoon has nothing to do with validation. Cocoon uses XML parser, and it >just passes this parameter (validate=true) to the parser. If parser is >not able to validate some xml (treeprocessor-builtins.xml in your case), >it is a bug either in XML or in parser. > > > > >>this means that all doctype resolution is for entity and attrib >>declarations only, doesn't it? >> >>i would have to validate all my input docs separately to ensure >>validity, which is ok for batch mode but very poor for dynamic use >> >>i'm asking about general intentions/views - i'll check out v2.1-dev >> >> >soon > > >>but i expect the problem will be the same >> >> > >Of course the same, unless you change XML parser implementation/version >or modify XML. > >PS See also on the same theme: >http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6200 > > >Vadim > > > > >>thanks in advance... >> >> > > >--------------------------------------------------------------------- >Please check that your question has not already been answered in the >FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> > >To unsubscribe, e-mail: <[EMAIL PROTECTED]> >For additional commands, e-mail: <[EMAIL PROTECTED]> > > > > --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
