You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Michael Hartle <mh...@hartle-klug.com> on 2001/12/14 00:44:53 UTC
[BUG] DTD validation shows bugs
Hello all,
after working and starting to slowly get pretty impressive, nearly
presentable results on coupling Documentum, Cocoon, Slide and OpenOffice
together, I found out that DTD validation is still a bit buggy in the
Cocoon 2.0 release:
1.) Whenever I used a pipeline like (any generator parsing XML with DTD)
=> (no transformer) => (HTML serializer), the first character returned
and visible astonishingly was always a ">". I assume this is Xerces
related, as changing the serializer type to "xml" produces an
ArrayOutOfBoundsException in the Xerces parser. To see this live, take
the entity catalog demo in the sitemap, remove the stylesheet
transformation to see the first bug and then change the serializer type
to "xml" to see the second. Adding an XSLT transformer to the pipeline,
even if it does not change anything, seems to be a workaround for now.
2.) After adding the OpenOffice DTD to the catalog and trying to
validate a content.xml with corresponds to the office.dtd, I encountered
the bug that whenever entities are to be resolved, the ISO*.pen files
are being searched in the same directory where the XML file to be
validated is located. After reverting a recent change to
org.apache.cocoon.components.resolver.ResolverImpl.java submitted by
Christian Schmitt (see
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100691270713121&w=2),
this issue was solved and any XML content produced by OpenOffice has
successfully been validated so far.
Has anyone seen such behavior too, or is it just me ? I am using a clean
Cocoon 2.0 release build with extensions like new generators, source
factories and the like which are closely modelled after existing
components. BTW, the Docbase source factory for interfacing Documentum
docbases yet has to be made configurable, but then it is close to donation.
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
Re: [BUG] DTD validation shows bugs
Posted by David Crossley <cr...@indexgeo.com.au>.
Michael Hartle wrote:
> David Crossley wrote:
>
> >Hi Christian, thanks for testing the entity resolver
> >on both platforms. You are the only one who has
> >bothered to reply.
>
> Sorry David, I yet had no chance of doing any test; I will try to reply
> with some of my findings as soon as I have obtained them.
Sorry from me. I forgot to allow the planet to rotate once
or twice before starting to panic.
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [BUG] DTD validation shows bugs
Posted by Christian Schmitt <cs...@ffzj0ia9.bank.dresdner.net>.
On Tue, Dec 18, 2001 at 07:44:46AM +1100, David Crossley wrote:
> Hi Christian, thanks for testing the entity resolver
> on both platforms. You are the only one who has
> bothered to reply.
>
> So what is the pathname for the successful catalog
> loading during situation 2) on Windows?
>
Hi David,
well, I'm not quite sure yet. At our project we're also building
PDF files from DocBook sources and we're using the entity
resolver as well. What I've found out so far, is that you absolutely
need to give the resolver an absolute path when telling it to load
a catalog file. What I've seen so far is that the resolver is then
building a file URL from the given path. But this URL sometimes
looks different, i.e. file://path/to/catalog and then
file:///path/to/some/other/catalog (note the two resp. three slashes).
When I have the time I'll look into it a little further.
Cheers,
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [BUG] DTD validation shows bugs
Posted by Michael Hartle <mh...@hartle-klug.com>.
David Crossley wrote:
>Hi Christian, thanks for testing the entity resolver
>on both platforms. You are the only one who has
>bothered to reply.
>
Sorry David, I yet had no chance of doing any test; I will try to reply
with some of my findings as soon as I have obtained them.
>So what is the pathname for the successful catalog
>loading during situation 2) on Windows?
>
When I finally sucessfully loaded the catalog and everything was running
fine, the "Loading catalog"-URL printed was
"jndi://localhost/cocoon/resources/entities/catalog" or something very,
very similar; I am sure about the "jndi" protocol part and anything up
to including "cocoon".
>Someone else will need to take over trying to solve
>this re-appearance of showstopper Bug #5060.
>It is beyond me.
>
Today I am going to have another look into it; maybe I can find some clues.
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
Re: [BUG] DTD validation shows bugs
Posted by David Crossley <cr...@indexgeo.com.au>.
Hi Christian, thanks for testing the entity resolver
on both platforms. You are the only one who has
bothered to reply.
So what is the pathname for the successful catalog
loading during situation 2) on Windows?
Someone else will need to take over trying to solve
this re-appearance of showstopper Bug #5060.
It is beyond me.
By the way, the entity resolver works in both situations
for me:
uname -a ... Linux 2.4.2-2
java -version ... Blackdown-1.3.1-FCS
--David
Christian Schmitt wrote:
> Hi,
> I update cocoon_20_branch and tried the webapp as well as
> the docs on the following platforms:
>
> a) Sun Solaris 8
> cs:~/cocoon_20_branch$ uname -a
> SunOS ffzj0ia9 5.8 Generic_108528-10 sun4u sparc SUNW,Ultra-250
> cs:~/cocoon_20_branch$ java -version
> java version "1.3.1_01"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_01)
> Java HotSpot(TM) Client VM (build 1.3.1_01, mixed mode)
>
> b) WinNT 4.0 (SP5)
> [c:\dev\cocoon_20_branch]java -version
> java version "1.3.1_01"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_01)
> Java HotSpot(TM) Client VM (build 1.3.1_01, mixed mode)
>
> On Sat, Dec 15, 2001 David Crossley wrote:
> > Would people on all platforms now see that the
> > entity resolver works for you.
> > 1) Use the Cocoon Samples "Entity Catalogs"
> Works on Solaris, but not on WinNT.
> Resolver prints following error message on NT:
> Catalog does not exist: file:/C:/dev/cocoon_20_branch/C:/dev/tomcat-3.2.3/webapps/cocoon/resources/entities/catalog
>
> > 2) build docs should get past userdocs/concepts/catalog-test.xml
> Works on both platforms.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [BUG] DTD validation shows bugs
Posted by Christian Schmitt <cs...@ffzj0ia9.bank.dresdner.net>.
Hi,
I update cocoon_20_branch and tried the webapp as well as
the docs on the following platforms:
a) Sun Solaris 8
cs:~/cocoon_20_branch$ uname -a
SunOS ffzj0ia9 5.8 Generic_108528-10 sun4u sparc SUNW,Ultra-250
cs:~/cocoon_20_branch$ java -version
java version "1.3.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_01)
Java HotSpot(TM) Client VM (build 1.3.1_01, mixed mode)
b) WinNT 4.0 (SP5)
[c:\dev\cocoon_20_branch]java -version
java version "1.3.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_01)
Java HotSpot(TM) Client VM (build 1.3.1_01, mixed mode)
On Sat, Dec 15, 2001 at 07:22:09PM +1100, David Crossley wrote:
> Would people on all platforms now see that the
> entity resolver works for you.
> 1) Use the Cocoon Samples "Entity Catalogs"
Works on Solaris, but not on WinNT.
Resolver prints following error message on NT:
Catalog does not exist: file:/C:/dev/cocoon_20_branch/C:/dev/tomcat-3.2.3/webapps/cocoon/resources/entities/catalog
> 2) build docs should get past userdocs/concepts/catalog-test.xml
Works on both platforms.
>
> cheers, David
>
Hth,
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [BUG] DTD validation shows bugs
Posted by David Crossley <cr...@indexgeo.com.au>.
OK the ResolverImpl.java has been mended.
It looks like we had a re-incarnation of Bug #5060
with platform-specific file: problems.
Would people on all platforms now see that the
entity resolver works for you.
1) Use the Cocoon Samples "Entity Catalogs"
2) build docs should get past userdocs/concepts/catalog-test.xml
cheers, David
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [BUG] DTD validation shows bugs
Posted by David Crossley <cr...@indexgeo.com.au>.
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
Re: [BUG] DTD validation shows bugs
Posted by Michael Hartle <mh...@hartle-klug.com>.
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, 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.
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.
>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.
>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.
>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.
>--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 ;)
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
Re: [BUG] DTD validation shows bugs
Posted by David Crossley <cr...@indexgeo.com.au>.
David Crossley wrote:
> Michael Hartle wrote:
<snip/>
> > 2.) After adding the OpenOffice DTD to the catalog and trying to
> > validate a content.xml with corresponds to the office.dtd, I encountered
> > the bug that whenever entities are to be resolved, the ISO*.pen files
> > are being searched in the same directory where the XML file to be
> > validated is located.
>
> This indicates to me that the whole entity resolver is not working.
> Are you sure that you have the catalog correctly configured?
> Raise the resolver parameter verbosity=3 in cocoon.xconf to see.
>
> 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.
> --David
I just checked 2.0 and all is OK for me.
> Michael continued:
> > After reverting a recent change to
> > org.apache.cocoon.components.resolver.ResolverImpl.java submitted by
> > Christian Schmitt (see
> > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100691270713121&w=2),
> > this issue was solved and any XML content produced by OpenOffice has
> > successfully been validated so far.
> >
> > Has anyone seen such behavior too, or is it just me ? I am using a clean
> > Cocoon 2.0 release build with extensions like new generators, source
> > factories and the like which are closely modelled after existing
> > components.
I have no problems. It works for me without reverting that patch.
It also works if i do revert the patch.
This is a Linux platform.
If you are sure that your catalog is configured properly, then
please look at Bugzilla Bug #5060 to see if that is the problem.
If you are not sure about your configuration for your new DTD,
then please outline your steps.
--David Crossley
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [BUG] DTD validation shows bugs
Posted by David Crossley <cr...@indexgeo.com.au>.
Michael Hartle wrote:
> Hello all,
>
> after working and starting to slowly get pretty impressive, nearly
> presentable results on coupling Documentum, Cocoon, Slide and
> OpenOffice together, I found out that DTD validation is still a bit
> buggy in the Cocoon 2.0 release:
You seem to have terminology mixed up a bit.
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.
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)
Also, entity resolution will need to happen in any case (i.e. even
if parser validation="false").
> 1.) Whenever I used a pipeline like (any generator parsing XML with DTD)
> => (no transformer) => (HTML serializer), the first character returned
> and visible astonishingly was always a ">". I assume this is Xerces
> related, as changing the serializer type to "xml" produces an
> ArrayOutOfBoundsException in the Xerces parser. To see this live, take
> the entity catalog demo in the sitemap, remove the stylesheet
> transformation to see the first bug and then change the serializer type
> to "xml" to see the second. Adding an XSLT transformer to the pipeline,
> even if it does not change anything, seems to be a workaround for now.
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.
> 2.) After adding the OpenOffice DTD to the catalog and trying to
> validate a content.xml with corresponds to the office.dtd, I encountered
> the bug that whenever entities are to be resolved, the ISO*.pen files
> are being searched in the same directory where the XML file to be
> validated is located.
This indicates to me that the whole entity resolver is not working.
Are you sure that you have the catalog correctly configured?
Raise the resolver parameter verbosity=3 in cocoon.xconf to see.
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.
--David
> After reverting a recent change to
> org.apache.cocoon.components.resolver.ResolverImpl.java submitted by
> Christian Schmitt (see
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100691270713121&w=2),
> this issue was solved and any XML content produced by OpenOffice has
> successfully been validated so far.
>
> Has anyone seen such behavior too, or is it just me ? I am using a clean
> Cocoon 2.0 release build with extensions like new generators, source
> factories and the like which are closely modelled after existing
> components. BTW, the Docbase source factory for interfacing Documentum
> docbases yet has to be made configurable, but then it is close to donation.
>
> 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
Avalon uses Cocoon, entity resolver fails -Was: [BUG] DTD validation shows bugs
Posted by David Crossley <cr...@indexgeo.com.au>.
Jeff Turner wrote:
> I've seen this behaviour when trying to add Catalog support to Avalon's
> Cocoon-based build system. Will try again with the patch reverted if I
> have time.
That would be because Avalon only includes the
cocoon.jar and does not have the supporting OASIS catalog
file. Follow cocoon/build.xml docs target which copies the
catalog and supporting entities into place in the build dir.
It would also need an entry for "resolver" in Avalon's
avalon/src/documentation/cocoon.xconf
.. follow the example in Cocoon's
cocoon/documentation/cocoon.xconf
Switch to DEBUG level in Avalon build.xml and look
for patterrn "System Catalog URL" ... you will see the resolver
trying to find the OASIS catalog.
There is talk of moving this stuff into Avalon so that
it provides wider support to all projects.
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [BUG] DTD validation shows bugs
Posted by Jeff Turner <je...@socialchange.net.au>.
On Fri, Dec 14, 2001 at 12:44:53AM +0100, Michael Hartle wrote:
[..]
> 2.) After adding the OpenOffice DTD to the catalog and trying to
> validate a content.xml with corresponds to the office.dtd, I encountered
> the bug that whenever entities are to be resolved, the ISO*.pen files
> are being searched in the same directory where the XML file to be
> validated is located. After reverting a recent change to
> org.apache.cocoon.components.resolver.ResolverImpl.java submitted by
> Christian Schmitt (see
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100691270713121&w=2),
> this issue was solved and any XML content produced by OpenOffice has
> successfully been validated so far.
>
>
> Has anyone seen such behavior too, or is it just me ?
I've seen this behaviour when trying to add Catalog support to Avalon's
Cocoon-based build system. Will try again with the patch reverted if I
have time.
--Jeff
[..]
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
spurious symbol ">" in pipeline -Was:[BUG] DTD validation shows bugs
Posted by David Crossley <cr...@indexgeo.com.au>.
Stefano Mazzocchi wrote:
> Michael Hartle wrote:
> > 1.) Whenever I used a pipeline like (any generator parsing XML with DTD)
> > => (no transformer) => (HTML serializer), the first character returned
> > and visible astonishingly was always a ">". I assume this is Xerces
> > related, as changing the serializer type to "xml" produces an
> > ArrayOutOfBoundsException in the Xerces parser. To see this live, take
> > the entity catalog demo in the sitemap, remove the stylesheet
> > transformation to see the first bug and then change the serializer type
> > to "xml" to see the second. Adding an XSLT transformer to the pipeline,
> > even if it does not change anything, seems to be a workaround for now.
>
> I have encountered this before. The problem with SAX is that doesn't
> guarantee well-formness as DOM does, being an event-driven approach, of
> course.
Hang on. The parser guarantees well-formedness. Try removing
closing </title> tag on index.xml then do "build docs". I suppose
that you mean that once Cocoon starts building a pipeline, and
potentially aggregating other SAX streams into it, then the overall
stream is not guaranteed to be well-formed.
The strange thing wilth Michael's demonstration, is that a bare ">"
has jumped into the pipeline ahead of the XML content stream.
The same happens if you similarly tweak the "hello" sitemap entry.
> The Xalan internal tree builder/indexer (DTM), seems to be kinda
> 'tollerant' in small SAX failures. Try enabling intra-pipe logging and
> see what that gives you.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [BUG] DTD validation shows bugs
Posted by Stefano Mazzocchi <st...@apache.org>.
Michael Hartle wrote:
>
> Hello all,
>
> after working and starting to slowly get pretty impressive, nearly
> presentable results on coupling Documentum, Cocoon, Slide and OpenOffice
> together
Uh, cool. Hope you're going to share your experience with us :) [maybe
an howto, hint, hint :)]
> I found out that DTD validation is still a bit buggy in the
> Cocoon 2.0 release:
>
> 1.) Whenever I used a pipeline like (any generator parsing XML with DTD)
> => (no transformer) => (HTML serializer), the first character returned
> and visible astonishingly was always a ">". I assume this is Xerces
> related, as changing the serializer type to "xml" produces an
> ArrayOutOfBoundsException in the Xerces parser. To see this live, take
> the entity catalog demo in the sitemap, remove the stylesheet
> transformation to see the first bug and then change the serializer type
> to "xml" to see the second. Adding an XSLT transformer to the pipeline,
> even if it does not change anything, seems to be a workaround for now.
I have encountered this before. The problem with SAX is that doesn't
guarantee well-formness as DOM does, being an event-driven approach, of
course.
The Xalan internal tree builder/indexer (DTM), seems to be kinda
'tollerant' in small SAX failures. Try enabling intra-pipe logging and
see what that gives you.
> 2.) After adding the OpenOffice DTD to the catalog and trying to
> validate a content.xml with corresponds to the office.dtd, I encountered
> the bug that whenever entities are to be resolved, the ISO*.pen files
> are being searched in the same directory where the XML file to be
> validated is located. After reverting a recent change to
> org.apache.cocoon.components.resolver.ResolverImpl.java submitted by
> Christian Schmitt (see
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100691270713121&w=2),
> this issue was solved and any XML content produced by OpenOffice has
> successfully been validated so far.
Cool. Has this patch being applied?
> Has anyone seen such behavior too, or is it just me ? I am using a clean
> Cocoon 2.0 release build with extensions like new generators, source
> factories and the like which are closely modelled after existing
> components. BTW, the Docbase source factory for interfacing Documentum
> docbases yet has to be made configurable, but then it is close to donation.
Cool.
A while ago, I rejected a donation about non-freely available software,
but I've changed my mind: as long as a donation is useful for somebody
and doesn't lag behind (I mean, it's not a code dump) I'm happy to
introduce it in the disto, even if it touches commercial software.
Of course, priorities still go to open-source solutions, but if you are
willing to pay for a service, that's your concern, not ours, and Cocoon
should be as interoperable as possible with existing (and future)
systems.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org