cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Aston" <>
Subject RE: Possible Entity Resolving Bug
Date Sun, 08 Sep 2002 09:56:08 GMT
Hi Antonio,

Whilst this works it's not really solving the problem.  Firstly, anything
with a public identifier can be correctly set up and resolved using catalogs
thus removing the need for the hard coding.  Also, this solution is only
workable at the serializer level - which is not applicable at the
generation/transformation stages when you will be processing XML resources
with their own DTD and entity resolution requirements.

What I am attempting to find out is why system ids are apparently not passed
across to the catalog resolver code for a DOCTYPE - is it correct behaviour,
is there a bug, or is it down to the configuration/operation of a specific
parser?  The parser is picking up the system id because it attempts to use
it as a result of not being able to resolve a match - so why is it not
passing it for matching?

Thanks for your response anyway.


 -----Original Message-----
From: 	Antonio Gallardo Rivera []
Sent:	08 September 2002 03:47
Subject:	Re: Possible Entity Resolving Bug

I resolved this simple problem making a hardcode for example:

<map:serializer logger="sitemap.serializer.html"
	name="html" pool-grow="4" pool-max="32" pool-min="4"
		-//W3C//DTD HTML 4.0//ES

Is this correct?

Antonio Gallardo

El Sábado, 07 de Septiembre de 2002 20:45, Jeremy Aston escribió:
> Hi,
> I have been doing some work with entity catlogs and have noticed some
> interesting behaviour.  It appears system ids are being ignored if used
> with a DOCTYPE declaration, only public ids are picked up.  I can
> successfully map something like:
> <!DOCTYPE person PUBLIC "-//PIGBITE//DTD Person V1.0//EN"
> "">
> using an entry like
> PUBLIC "-//PIGBITE//DTD Person V1.0//EN" "dtd/person.dtd"
> But
> <!DOCTYPE person "">
> does not get mapped even if
> SYSTEM" "dtd/person.dtd"
> is in the local catalog.
> I've noted that if a systemId is used to reference an entity - e.g.
> <!ENTITY jez SYSTEM "">
> and a corresponding map is in the catalog file:
> SYSTEM ""    "jez.txt"
> then this is resolved correctly.
> This does not appear to be a fundamental catalog problem.  I modified the
> entity catalog tests to test the above scenarios and everything worked.
> Interestingly the tests force the public Id and systemId args in the
> resolveEntity() method call, however further checks what gets passed to
> resolveEntity in org.apache.cocoon.components.resolver.ResolverImpl show
> that in the case of DOCTYPE the systemId arg is always NULL, regardless of
> if a systemId is present either on it's own or along with a publicid.  In
> the case of an ENTITY declaration the systemid and the publicid (if
> present) are always passed correctly.  It would appear that which ever bit
> of the doc parser picks up the entity references, it is not doing it as I
> would have expected.
> The catalog samples work fine, mainly because all the examples follow the
> above rules.  I know the local catalog is being loaded and have tested
> using the xml-commons tools, my modified cocoon test build and the fact
> that the resolution does take place if the "right" rules are followed.
> Trawling the lists I noted a previous message along similar lines that had
> no response, and I could not find anything else.  Is this behaviour
> or is it a bug?  I've looked at several other sites, including the OASIS
> spec and nothing seems to shed any light on it (other than implying that
> should work as expected) so If someone can advise I can either stop trying
> something that is not meant to happen or raise a bugzilla and do some more
> debugging.
> FYI I am using 2.0.3, JDK1.4, JAXP.  I have not yet tried it against the
> current HEAD code or using the XML catalog format (although I am sure the
> catalog itself is fine)
> jez

Please check that your question  has not already been answered in the
FAQ before posting.     <>

To unsubscribe, e-mail:     <>
For additional commands, e-mail:   <>

Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts

Please check that your question  has not already been answered in the
FAQ before posting.     <>

To unsubscribe, e-mail:     <>
For additional commands, e-mail:   <>

View raw message