Just to add a little more info...

I have taken note of the two search modes allowed (prefer=public or
prefer=system) in the CatalogManger.properties.  Every thing seems correct
here so this leads me even more to question exactly why <!DOCTYPE name
SYSTEM "ref"> is not passed to the catalog for matching but <!ENTITY name
SYSTEM "ref"> is.

Can anyone shed any light on this please?

ta

jez


                 -----Original Message-----
                From:   Jeremy Aston [mailto:[EMAIL PROTECTED]] 
                Sent:   08 September 2002 03:46
                To:     Cocoon-Users
                Subject:        Possible Entity Resolving Bug

                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";>

                using an entry like

                PUBLIC "-//PIGBITE//DTD Person V1.0//EN" "dtd/person.dtd"

                But 

                <!DOCTYPE person "http://www.pigbite.com/dtd/person.dtd";>

                does not get mapped even if 

                SYSTEM http://www.pigbite.com/dtd/person.dtd";
"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 "http://www.pigbite.com/dtd/jez.txt";>

                and a corresponding map is in the catalog file:

                SYSTEM "http://www.pigbite.com/dtd/jez.txt";    "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 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.

                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)

                TIA

                jez
                 << File: ATT00047.txt >> 

<<attachment: winmail.dat>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to