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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
|