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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
