You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Mikael St�ldal <mi...@home.se> on 2001/09/08 15:51:55 UTC
Hardcoded Crimson parser
Why is Batik hardcoded to use the Crimson parser?
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: Hardcoded Crimson parser
Posted by Mikael St�ldal <mi...@home.se>.
At 09:27 2001-09-13 +0200, Thierry Kormann wrote:
> > Why isn't JAXP used to find the parser to use?
>
>Batik is an SVG toolkit and the XML parser is really the low level part of
>our SVG implementation. In Batik, there is a class (XMLResourceDescriptor)
>that easily lets you control how to get the XML parser for *all* batik
>modules - so users can easily control how the XML parser is created (using
>JAXP or not).
Yes, but why isn't JAXP used to find the parser to use, if the user doesn't
explicitly specify one?
>We have decided to provide a low level solution on purpose. We don't see the
>need of using JAXP in our low level approach - but users can do it if they
>want to (how and which XML parser is better for their system).
The point of using JAXP is that the user doesn't have to invoke some method
in the Batik API, she only have to install her favorite JAXP compatible
parser in the CLASSPATH (perhaps Xerces).
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: Hardcoded Crimson parser
Posted by Thierry Kormann <tk...@ilog.fr>.
On Wednesday 12 September 2001 21:35, Mikael Ståldal wrote:
Hi,
> OK, but Crimson hardcoded as the default, isn't it?
What does that mean?
We don't want our users to have to specify an XML parser in order to use
batik - so we need to provide one amyway.
>
> Why isn't JAXP used to find the parser to use?
Batik is an SVG toolkit and the XML parser is really the low level part of
our SVG implementation. In Batik, there is a class (XMLResourceDescriptor)
that easily lets you control how to get the XML parser for *all* batik
modules - so users can easily control how the XML parser is created (using
JAXP or not).
We have decided to provide a low level solution on purpose. We don't see the
need of using JAXP in our low level approach - but users can do it if they
want to (how and which XML parser is better for their system).
Thanks for your comment.
Thierry.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: Hardcoded Crimson parser
Posted by Mikael St�ldal <mi...@home.se>.
At 09:57 2001-09-10 +0200, Stephane Hillion wrote:
>It is not.
OK, but Crimson hardcoded as the default, isn't it?
Why isn't JAXP used to find the parser to use?
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: Hardcoded Crimson parser
Posted by Stephane Hillion <sh...@ilog.fr>.
On Saturday 08 September 2001 15:51, Mikael Ståldal wrote:
> Why is Batik hardcoded to use the Crimson parser?
It is not.
The way to change the XML parser used in the Batik applications is to use
org.apache.batik.util.XMLResourceDescriptor.setXMLParserClassName().
--
Stephane.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org