Andy Clark wrote:
>
> I figured that thread was deep enough... ;)
>
> Ari wrote:
> > Is there a reason both versions of DOMParser, as well as
> > org.apache.xerces.xni.XMLDTDHandler don't use
> > org.xml.sax.ext.DeclHandler? The methods seem to have the same masks...
>
> Simply put, SAX doesn't
I figured that thread was deep enough... ;)
Ari wrote:
> Is there a reason both versions of DOMParser, as well as
> org.apache.xerces.xni.XMLDTDHandler don't use
> org.xml.sax.ext.DeclHandler? The methods seem to have the same masks...
Simply put, SAX doesn't communicate enough information. Also,
Andy Clark wrote:
>
> Xerces2 doesn't have a StringPool, so String objects are passed
> to the native interfaces. Both Xerces 1.x and Xerces2 have
> internal interfaces but at least we're trying to "standardize"
> the interfaces in Xerces2 (this is what we call XNI).
>
> In both versions, you can
Xerces2 doesn't have a StringPool, so String objects are passed
to the native interfaces. Both Xerces 1.x and Xerces2 have
internal interfaces but at least we're trying to "standardize"
the interfaces in Xerces2 (this is what we call XNI).
In both versions, you can directly extend the DOMParser cl
Andy Clark wrote:
>
> "K. Ari Krupnikov" wrote:
> > 1) add a constructor that takes a DOMImplementation argument and
> > overload init() and reset(). In this case,
>
> I like this solution. Either a constructor or having a
> property for the DOMImplementation object works for me.
> Perhaps the se
"K. Ari Krupnikov" wrote:
> xerces_j_2 DOMParser extends AbstractDOMParser; MAIN, XMLParser.
This was a mistake. Some experimental parser configuration work
was added to the HEAD accidentally; it should have been added
to the "xerces_j_2" branch. I think that Arnaud will be fixing
this shortly. Ri
Arnaud Le Hors wrote:
>
> "K. Ari Krupnikov" wrote:
> >
> > Ehh? I'm afraid I'm not on the cvs-commit list :=)
> >
> > Would it be reasonable to use the production (1.3) version, or has there
> > been significant work done?
>
> You can check out code anonymously. See http://xml.apache.org/cvs.htm
"K. Ari Krupnikov" wrote:
>
> Ehh? I'm afraid I'm not on the cvs-commit list :=)
>
> Would it be reasonable to use the production (1.3) version, or has there
> been significant work done?
You can check out code anonymously. See http://xml.apache.org/cvs.html
--
Arnaud Le Hors - IBM Cupertino,
Arnaud Le Hors wrote:
>
> "K. Ari Krupnikov" wrote:
> >
> > A stupid question - which cvs tag should I patch against?
>
> Definitely not stupid! I'd say it's your choice at this point. Which
> version of Xerces are you using? If it's Xerces1 just work off the
> trunc. If it's Xerces2 it's on the
"K. Ari Krupnikov" wrote:
>
> A stupid question - which cvs tag should I patch against?
Definitely not stupid! I'd say it's your choice at this point. Which
version of Xerces are you using? If it's Xerces1 just work off the
trunc. If it's Xerces2 it's on the branch Xerces_j_2. Hmm... As I say
th
Andy Clark wrote:
>
> "K. Ari Krupnikov" wrote:
> > 1) add a constructor that takes a DOMImplementation argument and
> > overload init() and reset(). In this case,
>
> I like this solution. Either a constructor or having a
> property for the DOMImplementation object works for me.
> Perhaps the se
Andy Clark wrote:
>
> "K. Ari Krupnikov" wrote:
> > 1) add a constructor that takes a DOMImplementation argument and
> > overload init() and reset(). In this case,
>
> I like this solution. Either a constructor or having a
> property for the DOMImplementation object works for me.
> Perhaps the se
"K. Ari Krupnikov" wrote:
> 1) add a constructor that takes a DOMImplementation argument and
> overload init() and reset(). In this case,
I like this solution. Either a constructor or having a
property for the DOMImplementation object works for me.
Perhaps the second is better because people creat
Andy Clark wrote:
>
> "K. Ari Krupnikov" wrote:
> > > Why is it not possible? Is this your own document impl or
> > > something else?
> >
> > It's my (and a few other people's) own.
> > http://sourceforge.net/projects/dbdom
>
> Okay, now I'm getting the picture...
>
> If you have any ideas as to
"K. Ari Krupnikov" wrote:
> > Why is it not possible? Is this your own document impl or
> > something else?
>
> It's my (and a few other people's) own.
> http://sourceforge.net/projects/dbdom
Okay, now I'm getting the picture...
If you have any ideas as to how to make your scenario (and
similar
Andy Clark wrote:
>
> "K. Ari Krupnikov" wrote:
> > > You don't need to subclass the parser itself; you only need to
> > > set the appropriate property on the parser to set the new DOM
> > > implementation by using the fully qualified class name. For
> > > example:
> > > [...]
> >
> > I'm afraid t
"K. Ari Krupnikov" wrote:
> > You don't need to subclass the parser itself; you only need to
> > set the appropriate property on the parser to set the new DOM
> > implementation by using the fully qualified class name. For
> > example:
> > [...]
>
> I'm afraid that's not possible. My Document does
Andy Clark wrote:
>
> "K. Ari Krupnikov" wrote:
> > What is the recommended way to use Xerces parser to build a DOM tree in
> > a different implementation?
> >
> > I subclassed org.apache.xerces.parsers.DOMParser such that
> > DEFAULT_DOCUMENT_CLASS_NAME is set to my Document implementation, and
>
"K. Ari Krupnikov" wrote:
> What is the recommended way to use Xerces parser to build a DOM tree in
> a different implementation?
>
> I subclassed org.apache.xerces.parsers.DOMParser such that
> DEFAULT_DOCUMENT_CLASS_NAME is set to my Document implementation, and
> fDocument is set to an empty Do
Hi,
What is the recommended way to use Xerces parser to build a DOM tree in
a different implementation?
I subclassed org.apache.xerces.parsers.DOMParser such that
DEFAULT_DOCUMENT_CLASS_NAME is set to my Document implementation, and
fDocument is set to an empty Document from my implementation. [1
20 matches
Mail list logo
