cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <cross...@indexgeo.com.au>
Subject Re: Possible Entity Resolving Bug
Date Sun, 08 Sep 2002 20:51:09 GMT
Jeremy Aston wrote:
> 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"
> "http://www.pigbite.com/dtd/person.dtd
> <http://www.pigbite.com/dtd/person.dtd> ">
> 
> using an entry like
> 
> PUBLIC "-//PIGBITE//DTD Person V1.0//EN" "dtd/person.dtd"
> 
> But 
> 
> <!DOCTYPE person "http://www.pigbite.com/dtd/person.dtd
> <http://www.pigbite.com/dtd/person.dtd> ">
> 
> does not get mapped even if 
> 
> SYSTEM http://www.pigbite.com/dtd/person.dtd
> <http://www.pigbite.com/dtd/person.dtd> " "dtd/person.dtd"
> 
> is in the local catalog.

I just did some tests and i can confirm that there is
something amiss. (Careful, the http... bits in your
examples are getting mangled by our mail readers...)
----
In the XML instance ...
<!DOCTYPE person SYSTEM "missing-person.dtd">

In the OASIS catalog ...
SYSTEM "missing-person.dtd" "person.dtd"
----
Yes, it does fail to resolve the systemId.

> I've noted that if a systemId is used to reference an entity - e.g. 
> 
> <!ENTITY jez SYSTEM "http://www.pigbite.com/dtd/jez.txt
> <http://www.pigbite.com/dtd/jez.txt> ">
> 
> and a corresponding map is in the catalog file:
> 
> SYSTEM "http://www.pigbite.com/dtd/jez.txt
> <http://www.pigbite.com/dtd/jez.txt> "    "jez.txt"
> 
> then this is resolved correctly.

Agreed. The Cocoon Sample catalog-demo declares an entity
this way and all is well.

> This does not appear to be a fundamental catalog problem.  I modified the
> entity catalog tests to test the above scenarios and everything worked.

I am not sure what you mean here. Are you saying that you
can get the SystemId resolved via "./build.sh test" whereas
it will not work via "./build.sh docs"?

> 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 that
> 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 correct 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 it
> 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.

Please do explore it further. The problem may be in
Cocoon's implementation of the entity resolver.

The actual resolver development can be discussed
on the xml-commons-dev mailing list.
http://xml.apache.org/commons/
http://marc.theaimsgroup.com/?l=xml-commons-dev

> 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)

I have not yet tried against HEAD, though i expect that it
will exhibit the same behaviour.
--David



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message