Hi David B & Alberto,
That is the change I am working on...
Regards,
David A. Cargill
XML Parser Development
IBM Toronto Lab
(905) 413-2371, tie 969
[EMAIL PROTECTED]
Alberto Massari
<[EMAIL PROTECTED]
s.com> To
[EMAIL PROTECTED]
12/03/2004 12:58 cc
PM
Subject
Re: DTD caching problems
Please respond to
xerces-c-dev
Hi David,
At 12.50 03/12/2004 -0500, [EMAIL PROTECTED] wrote:
>Hi Alberto,
>
>One problem I noticed with your fix is the call to resolveEntity() in the
>various overloads of resolveSystemId() always result in a null pointer for
>the public ID, meaning that any mechanism that relies on public IDs will
>not work. For example, in IGXMLScanner.::resolveSystemId():
>
> XMLResourceIdentifier
>resourceIdentifier(XMLResourceIdentifier::ExternalEntity,
> expSysId.getRawBuffer(), 0,
>XMLUni::fgZeroLenString, lastInfo.systemId);
> srcToFill = fEntityHandler->resolveEntity(&resourceIdentifier);
>
>You can see the XMLResourceIdentifier instance here is constructed with a
>null pointer for the public ID parameter.
>
>Perhaps changing the signature for resolveSystemId() to provide the public
>ID, if any, will solve this problem?
Yes, I too think that resolveSystemId should propagate the publicId (in my
commit I also fixed DGXMLScanner::resolveSystemId so that it propagates the
baseUri, as IGXMLScanner was doing)
Please go ahead and change the signature.
Thanks,
Alberto
>Thanks!
>
>Dave
>
>
>
>
>
>Alberto Massari <[EMAIL PROTECTED]>
>12/03/2004 09:14 AM
>Please respond to xerces-c-dev
>
> To: [EMAIL PROTECTED]
> cc: (bcc: David N Bertoni/Cambridge/IBM)
> Subject: Re: DTD caching problems
>
>Hi David,
>
>At 12.05 03/12/2004 -0500, David Cargill wrote:
>
> >Hi Alberto,
> >Looks like we are both working on the same problem. I have a different
> >solution for #1 and that is to call switchGrammar in scanDocType. That
>is
> >what happens in IGXMLScanner but not DGXMLScanner and that is why it
>works
> >for IG and not DG.
>
>I have thought about that, but I think that changing orphanGrammar would
>be
>a safer also for other cases when we forget to keep the two maps in synch.
>
>But feel free to revert my change.
>
>
> >For #2, still looking at how to avoid the 2nd call. Another customer
> >reported a similar problem as this as well...
>
>Have a look at what I committed, and let me know if this solves your
>problem too.
>
>Alberto
>
>
> >Regards,
> >David A. Cargill
> >XML Parser Development
> >IBM Toronto Lab
> >(905) 413-2371, tie 969
> >[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
