You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by Mark Weaver <ma...@npsl.co.uk> on 2004/04/07 14:19:02 UTC
exposing setXMLEntityResolver to the SAX parser
Would this be permissible? This is very useful, as the current
EntityResolver interface does not provide a base URI, leading to the problem
of it being impossible to correctly resolve a root document including a DTD
which includes another resource via a relative reference (and that's really
common -- most DTDs include other DTDs). A trivial example of such is
parsing and validating something specifiying:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
where xhtml1-strict.dtd has as it's first line:
<!ENTITY % HTMLlat1 PUBLIC
"-//W3C//ENTITIES Latin 1 for XHTML//EN"
"xhtml-lat1.ent">
%HTMLlat1
I tried to do this before by implementing EntityResolver2 (against 2.3.0)
but I came unstuck on the `name' parameter, where basically in a large
number of places I wasn't sure what to put for that. However, the new
method would work just fine for me, provided that I could get at it!
The patch below implements the change. The code is already present, so it
just exposes it...
Thanks,
Mark
diff -ur xerces-c-src_2_5_0\src\xercesc/sax2/SAX2XMLReader.hpp
xml-xerces\src\xercesc/sax2/SAX2XMLReader.hpp
--- xerces-c-src_2_5_0\src\xercesc/sax2/SAX2XMLReader.hpp 2004-02-16
20:52:16.000000000 +0000
+++ xml-xerces\src\xercesc/sax2/SAX2XMLReader.hpp 2004-04-07
01:41:56.583227000 +0100
@@ -173,6 +173,7 @@
class ContentHandler ;
class DTDHandler;
+class XMLEntityResolver;
class EntityResolver;
class ErrorHandler;
class InputSource;
@@ -249,6 +250,13 @@
virtual EntityResolver* getEntityResolver() const = 0 ;
/**
+ * This method returns the installed entity resolver.
+ *
+ * @return A pointer to the installed entity resolver object.
+ */
+ virtual XMLEntityResolver* getXMLEntityResolver() const = 0 ;
+
+ /**
* This method returns the installed error handler.
*
* @return A pointer to the installed error handler object.
@@ -338,6 +346,24 @@
*/
virtual void setEntityResolver(EntityResolver* const resolver) = 0;
+ /** Set the entity resolver
+ *
+ * This method allows applications to install their own entity
+ * resolver. By installing an entity resolver, the applications
+ * can trap and potentially redirect references to external
+ * entities.
+ *
+ * <i>Any previously set entity resolver is merely dropped, since the
parser
+ * does not own them. If both setEntityResolver and
setXMLEntityResolver
+ * are called, then the last one is used.</i>
+ *
+ * @param resolver A const pointer to the user supplied entity
+ * resolver.
+ *
+ * @see #getXMLEntityResolver
+ */
+ virtual void setXMLEntityResolver(XMLEntityResolver* const resolver) =
0;
+
/**
* Allow an application to register an error event handler.
*
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: exposing setXMLEntityResolver to the SAX parser
Posted by Mark Weaver <ma...@npsl.co.uk>.
> >Where I came unstuck was the name parameter:
> >
> >name - Identifies the external entity being resolved. Either
> "[dtd]" for the
> >external subset, or a name starting with "%" to indicate a
> parameter entity,
> >or else the name of a general entity. This is never null when
> invoked by a
> >SAX2 parser.
> >
> >I haven't much of a clue how to do that.
>
> It looks like the specs don't take into consideration XML Schema; what
> should "name" contain in that case?
> If this resolver should be invoked only when a DTD entity is being
> resolver, the informations is almost there; the LastExtEntityInfo
> structure
> needs to be extended with a "name" field, that getLastExtEntityInfo would
> fill by using the XMLEntityDecl currently in scope.
>
>
OK, that doesn't quite work:
a) The names don't look like those specified in the spec, which has %
starting parameter entities and [dtd] for the dtd.
b) getLastExtEntityInfo is returning information for the _previous_ element.
resolveEntity() is called during the process of parsing the element, e.g.
<!ENTITY % HTMLlat1 PUBLIC
"-//W3C//ENTITIES Latin 1 for XHTML//EN"
"xhtml-lat1.ent">
%HTMLlat1;
at this point, the available name is wrong.
So basically, that's the wrong information.
The simplest way I could see around this is to pass the name into
createReader in ReaderMgr all over the place (defaulting to NULL), and then
DTDScanner.cpp gets to fill this information out at the appropriate time.
Any further pointers?
As an alternative way around my problem, and possibly in addition anyway,
could we perhaps resolve the systemId relative to the appropriate base URI
before calling resolveEntity() in the plain ER1? Basically, going back to
my original problem, there isn't enough context provided giving just the
unresolved entity URI and no base URI to actually figure out where to find
the resource. This as far as I can tell makes the original EntityResolver
essentially useless, so having thought of that, maybe the fact that this
isn't done already is just a bug?
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: exposing setXMLEntityResolver to the SAX parser
Posted by Mark Weaver <ma...@npsl.co.uk>.
> >- Changing resolveEntity everywhere to take a name and baseURI parameter
> >- Calling the appropriate resolver (via getEntityResolverVersion and
> >static_cast)
>
> The appropriate resolver should be invoked by looking at the
> use-entity-resolver2 feature (that the user could decide to turn off even
> if she provides an EntityResolver2 interface)
>
The spec seems to imply that this flag should be set if the implementation
supports ER2, and that the client can use this feature to determine if it is
supported. Since if you want ER1 behaviour, you just pass an ER1 class to
setEntityResolver, it would seem unnecessary to support passing in an ER2
object and turning off the feature that allows it to be used. I can't
really see a situation where you would want ER1 behaviour, but with an ER2
object -- you are most likely to want it if it is present, otherwise you'd
just use an ER1 object instead. I don't see that the spec allows you to
turn this feature off explicitly, but if all the other features are RW then
I suppose that would make sense by extension.
If it really is necessary to support that, then it still comes back to each
of the many places that have an ER1 resolver installed (via the SAX parser)
having either a further pointer, or a flag, to an ER2 interface.
(Alternatively, they need to be able to get back to the SAX parser that
created them, and then query for the feature, which is beginning to sound
pretty revolting...)
> It looks like the specs don't take into consideration XML Schema; what
> should "name" contain in that case?
I have no idea!
> If this resolver should be invoked only when a DTD entity is being
> resolver, the informations is almost there; the LastExtEntityInfo
> structure
> needs to be extended with a "name" field, that getLastExtEntityInfo would
> fill by using the XMLEntityDecl currently in scope.
>
Right, I can have a go at that.
> >Then I'm also left with the getExternalSubset() function, which again, I
> >don't know where or how to implement.
>
> It should probably be handled like the setExternalSchemaLocation is
> handled; when isRoot is true and the setting has been set, the
> resolver is
> invoked and the DTD is parsed like it was specified in the prolog.
>
I'm not entirely clear about that, but I'll have another look around the
code and see if it makes any more sense.
Thanks,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: exposing setXMLEntityResolver to the SAX parser
Posted by Alberto Massari <am...@progress.com>.
At 13.13 08/04/2004 +0100, Mark Weaver wrote:
> > Hi Mark,
> > I guess the reason these methods have not been added to SAX2XMLReader is
> > that this interface is derived from the SAX2 specs, where they
> > are missing.
> > If you can provide a patch using the EntityResolver2 extension,
> > that would
> > be a better fix for this problem.
> >
>I'm not really sure how to do this. Last time, I got as far as:
>
>- Adding an EntityResolver2 class defined as per SAX2 spec
>- Adding a getEntityResolverVersion function to EntityResolver so as to be
>able to distinguish between the two at runtime
Maybe we could avoid this by adding an overloaded
setEntityResolver(EntityResolver2*) that would automatically detect the new
interface (and set the
http://xml.org/sax/features/use-entity-resolver2 feature)
>- Changing resolveEntity everywhere to take a name and baseURI parameter
>- Calling the appropriate resolver (via getEntityResolverVersion and
>static_cast)
The appropriate resolver should be invoked by looking at the
use-entity-resolver2 feature (that the user could decide to turn off even
if she provides an EntityResolver2 interface)
>Where I came unstuck was the name parameter:
>
>name - Identifies the external entity being resolved. Either "[dtd]" for the
>external subset, or a name starting with "%" to indicate a parameter entity,
>or else the name of a general entity. This is never null when invoked by a
>SAX2 parser.
>
>I haven't much of a clue how to do that.
It looks like the specs don't take into consideration XML Schema; what
should "name" contain in that case?
If this resolver should be invoked only when a DTD entity is being
resolver, the informations is almost there; the LastExtEntityInfo structure
needs to be extended with a "name" field, that getLastExtEntityInfo would
fill by using the XMLEntityDecl currently in scope.
>Now I see that we have the old style resolveEntity method, and a new one
>that takes an XMLResourceIdentifier. XMLResourceIdentifier does not include
>a name, but it seems that these days the resolveEntity method is ignored
>(comments indicate that it is not called, but that the other one is instead,
>which seems true on a quick reading). I guess the sensible approach would
>be:
>
>- Add a name member to XMLResourceIdentifier
>- Find out what to put in the name every time one of these is created
>- Have the new resolveEntity check for ER2 being installed and call the
>appropriate method passing on the name parameter
>
>Then I'm also left with the getExternalSubset() function, which again, I
>don't know where or how to implement.
It should probably be handled like the setExternalSchemaLocation is
handled; when isRoot is true and the setting has been set, the resolver is
invoked and the DTD is parsed like it was specified in the prolog.
Alberto
>There's also a problem with the ER2 vs ER method in that you are supposed to
>be able to turn off using ER2 via the SAX2 feature
>http://xml.org/sax/features/use-entity-resolver2. Obviously the ER2 method
>then needs some way of knowing which kind of entity resolver it is meant to
>be, and the simple test above is not enough for that. OTOMH you'd need to
>do something like storing pointers to
>
>a) an EntityResolver
>and
>b) an EntityResolver2
>
>everywhere. setEntityResolver on the SAX2 interface can then check the
>feature flag and store the appropriate one (which would then pass off the
>appropriate ER/ER2 to the other scanners which are invoked, e.g. for the
>DTD/XSD, where each of these would need to have a slightly different
>interface featuring a setEntityResolver2.
>
>It's beginning to sound very messy (unless there is a better solution, which
>there may well be), as we now have three ways of installing three different
>kinds of incompatible entity resolvers.
>
>Simply exposing setXMLEntityResolver isn't actually enough for me: I'm using
>Xerces through Xalan (which I assume is fairly common), so then a chunk of
>Xalan (including interfaces) needs to change to expose this as well, so
>that's not ideal either. With the old method (which admittedly was
>terminally broken wrt to the spec) but did the job for me, there were no
>external interface changes, and therefore no changes needed in Xalan, which
>is a plus.
>
>Any help as to which way to go would be appreciated.
>
>Thanks,
>
>Mark
>
> > Alberto
> >
> > At 13.19 07/04/2004 +0100, Mark Weaver wrote:
> > >Would this be permissible? This is very useful, as the current
> > >EntityResolver interface does not provide a base URI, leading to
> > the problem
> > >of it being impossible to correctly resolve a root document
> > including a DTD
> > >which includes another resource via a relative reference (and
> > that's really
> > >common -- most DTDs include other DTDs). A trivial example of such is
> > >parsing and validating something specifiying:
> > >
> > ><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
> > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
> > >
> > >where xhtml1-strict.dtd has as it's first line:
> > >
> > ><!ENTITY % HTMLlat1 PUBLIC
> > > "-//W3C//ENTITIES Latin 1 for XHTML//EN"
> > > "xhtml-lat1.ent">
> > >%HTMLlat1
> > >
> > >I tried to do this before by implementing EntityResolver2 (against 2.3.0)
> > >but I came unstuck on the `name' parameter, where basically in a large
> > >number of places I wasn't sure what to put for that. However, the new
> > >method would work just fine for me, provided that I could get at it!
> > >
> > >The patch below implements the change. The code is already
> > present, so it
> > >just exposes it...
> > >
> > >Thanks,
> > >
> > >Mark
> > >
> > >diff -ur xerces-c-src_2_5_0\src\xercesc/sax2/SAX2XMLReader.hpp
> > >xml-xerces\src\xercesc/sax2/SAX2XMLReader.hpp
> > >--- xerces-c-src_2_5_0\src\xercesc/sax2/SAX2XMLReader.hpp
> > 2004-02-16
> > >20:52:16.000000000 +0000
> > >+++ xml-xerces\src\xercesc/sax2/SAX2XMLReader.hpp 2004-04-07
> > >01:41:56.583227000 +0100
> > >@@ -173,6 +173,7 @@
> > >
> > > class ContentHandler ;
> > > class DTDHandler;
> > >+class XMLEntityResolver;
> > > class EntityResolver;
> > > class ErrorHandler;
> > > class InputSource;
> > >@@ -249,6 +250,13 @@
> > > virtual EntityResolver* getEntityResolver() const = 0 ;
> > >
> > > /**
> > >+ * This method returns the installed entity resolver.
> > >+ *
> > >+ * @return A pointer to the installed entity resolver object.
> > >+ */
> > >+ virtual XMLEntityResolver* getXMLEntityResolver() const = 0 ;
> > >+
> > >+ /**
> > > * This method returns the installed error handler.
> > > *
> > > * @return A pointer to the installed error handler object.
> > >@@ -338,6 +346,24 @@
> > > */
> > > virtual void setEntityResolver(EntityResolver* const resolver) = 0;
> > >
> > >+ /** Set the entity resolver
> > >+ *
> > >+ * This method allows applications to install their own entity
> > >+ * resolver. By installing an entity resolver, the applications
> > >+ * can trap and potentially redirect references to external
> > >+ * entities.
> > >+ *
> > >+ * <i>Any previously set entity resolver is merely dropped, since the
> > >parser
> > >+ * does not own them. If both setEntityResolver and
> > >setXMLEntityResolver
> > >+ * are called, then the last one is used.</i>
> > >+ *
> > >+ * @param resolver A const pointer to the user supplied entity
> > >+ * resolver.
> > >+ *
> > >+ * @see #getXMLEntityResolver
> > >+ */
> > >+ virtual void setXMLEntityResolver(XMLEntityResolver* const
> > resolver) =
> > >0;
> > >+
> > > /**
> > > * Allow an application to register an error event handler.
> > > *
> > >
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > >For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
> >
> >
> >
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
>For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: exposing setXMLEntityResolver to the SAX parser
Posted by Mark Weaver <ma...@npsl.co.uk>.
Replying to myself:
> There's also a problem with the ER2 vs ER method in that you are
> supposed to
> be able to turn off using ER2 via the SAX2 feature
> http://xml.org/sax/features/use-entity-resolver2.
SAX2 spec:
"If a SAX application requires the customized handling which this interface
defines for external entities, it must ensure that it uses an XMLReader with
the http://xml.org/sax/features/use-entity-resolver2 feature flag set to
true (which is its default value when the feature is recognized). If that
flag is unrecognized, or its value is false, or the resolver does not
implement this interface, then only the EntityResolver method will be used."
Presumably there's therefore no requirement that you be able to turn this
feature off? (Which does simplify things quite a bit as the original method
of checking the entity resolver version prior to calling will work).
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: exposing setXMLEntityResolver to the SAX parser
Posted by Mark Weaver <ma...@npsl.co.uk>.
> Hi Mark,
> I guess the reason these methods have not been added to SAX2XMLReader is
> that this interface is derived from the SAX2 specs, where they
> are missing.
> If you can provide a patch using the EntityResolver2 extension,
> that would
> be a better fix for this problem.
>
I'm not really sure how to do this. Last time, I got as far as:
- Adding an EntityResolver2 class defined as per SAX2 spec
- Adding a getEntityResolverVersion function to EntityResolver so as to be
able to distinguish between the two at runtime
- Changing resolveEntity everywhere to take a name and baseURI parameter
- Calling the appropriate resolver (via getEntityResolverVersion and
static_cast)
Where I came unstuck was the name parameter:
name - Identifies the external entity being resolved. Either "[dtd]" for the
external subset, or a name starting with "%" to indicate a parameter entity,
or else the name of a general entity. This is never null when invoked by a
SAX2 parser.
I haven't much of a clue how to do that.
Now I see that we have the old style resolveEntity method, and a new one
that takes an XMLResourceIdentifier. XMLResourceIdentifier does not include
a name, but it seems that these days the resolveEntity method is ignored
(comments indicate that it is not called, but that the other one is instead,
which seems true on a quick reading). I guess the sensible approach would
be:
- Add a name member to XMLResourceIdentifier
- Find out what to put in the name every time one of these is created
- Have the new resolveEntity check for ER2 being installed and call the
appropriate method passing on the name parameter
Then I'm also left with the getExternalSubset() function, which again, I
don't know where or how to implement.
There's also a problem with the ER2 vs ER method in that you are supposed to
be able to turn off using ER2 via the SAX2 feature
http://xml.org/sax/features/use-entity-resolver2. Obviously the ER2 method
then needs some way of knowing which kind of entity resolver it is meant to
be, and the simple test above is not enough for that. OTOMH you'd need to
do something like storing pointers to
a) an EntityResolver
and
b) an EntityResolver2
everywhere. setEntityResolver on the SAX2 interface can then check the
feature flag and store the appropriate one (which would then pass off the
appropriate ER/ER2 to the other scanners which are invoked, e.g. for the
DTD/XSD, where each of these would need to have a slightly different
interface featuring a setEntityResolver2.
It's beginning to sound very messy (unless there is a better solution, which
there may well be), as we now have three ways of installing three different
kinds of incompatible entity resolvers.
Simply exposing setXMLEntityResolver isn't actually enough for me: I'm using
Xerces through Xalan (which I assume is fairly common), so then a chunk of
Xalan (including interfaces) needs to change to expose this as well, so
that's not ideal either. With the old method (which admittedly was
terminally broken wrt to the spec) but did the job for me, there were no
external interface changes, and therefore no changes needed in Xalan, which
is a plus.
Any help as to which way to go would be appreciated.
Thanks,
Mark
> Alberto
>
> At 13.19 07/04/2004 +0100, Mark Weaver wrote:
> >Would this be permissible? This is very useful, as the current
> >EntityResolver interface does not provide a base URI, leading to
> the problem
> >of it being impossible to correctly resolve a root document
> including a DTD
> >which includes another resource via a relative reference (and
> that's really
> >common -- most DTDs include other DTDs). A trivial example of such is
> >parsing and validating something specifiying:
> >
> ><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
> > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
> >
> >where xhtml1-strict.dtd has as it's first line:
> >
> ><!ENTITY % HTMLlat1 PUBLIC
> > "-//W3C//ENTITIES Latin 1 for XHTML//EN"
> > "xhtml-lat1.ent">
> >%HTMLlat1
> >
> >I tried to do this before by implementing EntityResolver2 (against 2.3.0)
> >but I came unstuck on the `name' parameter, where basically in a large
> >number of places I wasn't sure what to put for that. However, the new
> >method would work just fine for me, provided that I could get at it!
> >
> >The patch below implements the change. The code is already
> present, so it
> >just exposes it...
> >
> >Thanks,
> >
> >Mark
> >
> >diff -ur xerces-c-src_2_5_0\src\xercesc/sax2/SAX2XMLReader.hpp
> >xml-xerces\src\xercesc/sax2/SAX2XMLReader.hpp
> >--- xerces-c-src_2_5_0\src\xercesc/sax2/SAX2XMLReader.hpp
> 2004-02-16
> >20:52:16.000000000 +0000
> >+++ xml-xerces\src\xercesc/sax2/SAX2XMLReader.hpp 2004-04-07
> >01:41:56.583227000 +0100
> >@@ -173,6 +173,7 @@
> >
> > class ContentHandler ;
> > class DTDHandler;
> >+class XMLEntityResolver;
> > class EntityResolver;
> > class ErrorHandler;
> > class InputSource;
> >@@ -249,6 +250,13 @@
> > virtual EntityResolver* getEntityResolver() const = 0 ;
> >
> > /**
> >+ * This method returns the installed entity resolver.
> >+ *
> >+ * @return A pointer to the installed entity resolver object.
> >+ */
> >+ virtual XMLEntityResolver* getXMLEntityResolver() const = 0 ;
> >+
> >+ /**
> > * This method returns the installed error handler.
> > *
> > * @return A pointer to the installed error handler object.
> >@@ -338,6 +346,24 @@
> > */
> > virtual void setEntityResolver(EntityResolver* const resolver) = 0;
> >
> >+ /** Set the entity resolver
> >+ *
> >+ * This method allows applications to install their own entity
> >+ * resolver. By installing an entity resolver, the applications
> >+ * can trap and potentially redirect references to external
> >+ * entities.
> >+ *
> >+ * <i>Any previously set entity resolver is merely dropped, since the
> >parser
> >+ * does not own them. If both setEntityResolver and
> >setXMLEntityResolver
> >+ * are called, then the last one is used.</i>
> >+ *
> >+ * @param resolver A const pointer to the user supplied entity
> >+ * resolver.
> >+ *
> >+ * @see #getXMLEntityResolver
> >+ */
> >+ virtual void setXMLEntityResolver(XMLEntityResolver* const
> resolver) =
> >0;
> >+
> > /**
> > * Allow an application to register an error event handler.
> > *
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> >For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: exposing setXMLEntityResolver to the SAX parser
Posted by Alberto Massari <am...@progress.com>.
Hi Mark,
I guess the reason these methods have not been added to SAX2XMLReader is
that this interface is derived from the SAX2 specs, where they are missing.
If you can provide a patch using the EntityResolver2 extension, that would
be a better fix for this problem.
Alberto
At 13.19 07/04/2004 +0100, Mark Weaver wrote:
>Would this be permissible? This is very useful, as the current
>EntityResolver interface does not provide a base URI, leading to the problem
>of it being impossible to correctly resolve a root document including a DTD
>which includes another resource via a relative reference (and that's really
>common -- most DTDs include other DTDs). A trivial example of such is
>parsing and validating something specifiying:
>
><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
>
>where xhtml1-strict.dtd has as it's first line:
>
><!ENTITY % HTMLlat1 PUBLIC
> "-//W3C//ENTITIES Latin 1 for XHTML//EN"
> "xhtml-lat1.ent">
>%HTMLlat1
>
>I tried to do this before by implementing EntityResolver2 (against 2.3.0)
>but I came unstuck on the `name' parameter, where basically in a large
>number of places I wasn't sure what to put for that. However, the new
>method would work just fine for me, provided that I could get at it!
>
>The patch below implements the change. The code is already present, so it
>just exposes it...
>
>Thanks,
>
>Mark
>
>diff -ur xerces-c-src_2_5_0\src\xercesc/sax2/SAX2XMLReader.hpp
>xml-xerces\src\xercesc/sax2/SAX2XMLReader.hpp
>--- xerces-c-src_2_5_0\src\xercesc/sax2/SAX2XMLReader.hpp 2004-02-16
>20:52:16.000000000 +0000
>+++ xml-xerces\src\xercesc/sax2/SAX2XMLReader.hpp 2004-04-07
>01:41:56.583227000 +0100
>@@ -173,6 +173,7 @@
>
> class ContentHandler ;
> class DTDHandler;
>+class XMLEntityResolver;
> class EntityResolver;
> class ErrorHandler;
> class InputSource;
>@@ -249,6 +250,13 @@
> virtual EntityResolver* getEntityResolver() const = 0 ;
>
> /**
>+ * This method returns the installed entity resolver.
>+ *
>+ * @return A pointer to the installed entity resolver object.
>+ */
>+ virtual XMLEntityResolver* getXMLEntityResolver() const = 0 ;
>+
>+ /**
> * This method returns the installed error handler.
> *
> * @return A pointer to the installed error handler object.
>@@ -338,6 +346,24 @@
> */
> virtual void setEntityResolver(EntityResolver* const resolver) = 0;
>
>+ /** Set the entity resolver
>+ *
>+ * This method allows applications to install their own entity
>+ * resolver. By installing an entity resolver, the applications
>+ * can trap and potentially redirect references to external
>+ * entities.
>+ *
>+ * <i>Any previously set entity resolver is merely dropped, since the
>parser
>+ * does not own them. If both setEntityResolver and
>setXMLEntityResolver
>+ * are called, then the last one is used.</i>
>+ *
>+ * @param resolver A const pointer to the user supplied entity
>+ * resolver.
>+ *
>+ * @see #getXMLEntityResolver
>+ */
>+ virtual void setXMLEntityResolver(XMLEntityResolver* const resolver) =
>0;
>+
> /**
> * Allow an application to register an error event handler.
> *
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
>For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org