Michael Hartle wrote: > David Crossley wrote: > >You seem to have terminology mixed up a bit. > > > Okay, I agree - it was late when I composed the email, but I will try to > correct the message. > > >Do you mean "XML validation" to ensure that the structure of the > >XML instance conforms to the rules of its DTD? > >Or do you mean "entity resolution" to allow the parser to find > >a local copy of your new DTD? > >Your discussion below indicates the latter. > > > When using OpenOffice-produced content, I first stumbled on the > <!DOCTYPE PUBLIC "-//somthingIcannotremember//-" "office.dtd"> > declaration in the content.xml file; when the parser came across the > file, it tried to look up the DTD, which was not there, resulting in an > error whenever I tried to process the content. After looking around, I > found the office.dtd plus several files that are included in there in a > subdirectory of an OO installation. I then added a new subdirectory > called "openoffice" to "resources/entities" and added the proper > declaration to the catalog configuration file as well. > > The error about the lacking DTD then vanished,
That sound like the entity resolver activated then - good. > but my sample still did > not work as expected, producing exceptions. To make a long debugging and > tracing-through-classes story short, I finally traced the reason for the > problem back to the ResolverImpl and somehow remembered this particular > commit message which I then found at marc.theaimsgroup.com. After > reverting this patch, both the entity resolution catalog and my sample > worked perfectly. Well done. (See discussion of consequences below.) > I might be wrong and currently I cannot remember it exactly, but I > believe that before I reverted the patch, I turned up verbosity and > tried the entity resolution catalog sample on the welcome page - I think > it then failed, too. > > >The "entity resolution" should happen by default (as long as > >you have your "catalog" configured). The "XML Validation" > >you need to switch on via xconf (see documentation/cocoon.xconf) > > > Searching for "validation", I could not find anything that relates to a > parser validation switch in documentation/cocoon.xconf in the Cocoon 2.0 > release. Sorry, i meant 2.1 HEAD. That parameter is only documented there. It is in the <parser> entry ... parameter name="validate" (Careful, you will get troubles at this stage - hence 2.1 I tried some discussion threads last month about validation but there was no response.) > >Also, entity resolution will need to happen in any case (i.e. even > >if parser validation="false"). > > > I did not touch a switch like that, so I guess the default setting would > apply here. Yes, default is no validation ... validate="false" > >I do not understand what you are trying to achieve here. > >Generate XML => Serialize HTML does not make sense to me. > >Perhaps you are trying to demonstrate some other error. > > > Anything that travels inside the pipeline is XML, so when the generated > XML is e.g. an XHTML conforming file, it must be possible to directly > serialize this; this has been working perfectly so far when the XML > contained no DOCTYPE declaration at all. When developing, I start with > the basic combination of generator and serializer, then slowly adding > transformers and visually controlling the serialized XML step by step > until all transformations are being done correctly and the resulting > markup is the way I want; finally I switch the serializer type to what I > need, obtaining the final output. It is not something I tried to achieve > first hand, rather a behaviour I stumbled across when starting my work > without a transformer in a pipeline. That sounds like an excellent approach - thanks for taking the time to explain. I will adopt it. So where does the spurious ">" come from? This was your issue #1 in your original posting. I think that this is a separate issue which would better be discussed in a new thread. What do you think? > >I am currently updating my 2.0 working copy and will check myself. > >I was sure that i tested stuff after committing Christian's patch. > >Let us pray that Bug 5060 (platform-specific problems with file:) > >has not crawled back to life. > > > Sorry to spoil the party, but this particular system of mine is a > Windows NT 4.0 server, running on JDK 1.3.1. So it sounds like we do not need the patch at all - or is it there for other reasons. What does this mean for the recent 2.0 release? ... i will look tomorrow. It seems that, with the flurry of release and two last-day showstoppers, platform testing was missed. > >--David > > > BTW, should you come to Frankfurt/Main, Germany one day, mention it and > feel yourself invited to a beer or two. By adding the OASIS catalog > capability to Cocoon, you pretty much saved me a lot of work in my > current project ;) OK, alternatively, or as well as, you could pop downunder :-) We are coming up to a hot Aussie summer. I knew that we would ALL need OASIS catalog capability. My projects could not be done without it. Many thanks to all for its beaut cocoon. --David Crossley > Best regards, > > Michael Hartle, > Hartle & Klug GbR --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
