preferred xml parser

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

preferred xml parser

Thorsten Scherler-3
Hi all,

looking at the source code I wonder whether we have a preferred xml
parser model?

I mean I can find:
- pull parsing
- DOM
- JDOM (at least in some jira patches)

SAX I have not seen yet and neither StAX. I made some very good
experience with StAX lately it is fast and easy to use.

Do we plan to recommend one technique (at least for the core)?
Do we have plans to create an interface for a SolrDocumentFactory? This
way we could have various underlying implementation returning always the
same: xml.

I ask because I may look into SOLR-20 and SOLR-30 and would like to use
StAX as underlying parser.

salu2

Reply | Threaded
Open this post in threaded view
|

Re: preferred xml parser

Bill Au
StAX is now supported in JSE6, which has just been released.
I also found StAX to be very fast and easy to use.

Bill

On 12/20/06, Thorsten Scherler <[hidden email]>
wrote:

>
> Hi all,
>
> looking at the source code I wonder whether we have a preferred xml
> parser model?
>
> I mean I can find:
> - pull parsing
> - DOM
> - JDOM (at least in some jira patches)
>
> SAX I have not seen yet and neither StAX. I made some very good
> experience with StAX lately it is fast and easy to use.
>
> Do we plan to recommend one technique (at least for the core)?
> Do we have plans to create an interface for a SolrDocumentFactory? This
> way we could have various underlying implementation returning always the
> same: xml.
>
> I ask because I may look into SOLR-20 and SOLR-30 and would like to use
> StAX as underlying parser.
>
> salu2
>
>
Reply | Threaded
Open this post in threaded view
|

Re: preferred xml parser

Yonik Seeley-2
In reply to this post by Thorsten Scherler-3
On 12/20/06, Thorsten Scherler
<[hidden email]> wrote:
> looking at the source code I wonder whether we have a preferred xml
> parser model?
>
> I mean I can find:
> - pull parsing
> - DOM
> - JDOM (at least in some jira patches)

IMO, DOM & xpath is good for config.  xpath is easy, flexible and less
error prone, and we aren't concerned with performance for reading
config.

Pull parsing (StAX) for anything performance critical.

XPP was used at the start, but I think there is a longer term plan to
go with StAX.
http://www.nabble.com/XPP-license-tf1468633.html#a3977357

> SAX I have not seen yet and neither StAX. I made some very good
> experience with StAX lately it is fast and easy to use.
>
> Do we plan to recommend one technique (at least for the core)?
> Do we have plans to create an interface for a SolrDocumentFactory? This
> way we could have various underlying implementation returning always the
> same: xml.
>
> I ask because I may look into SOLR-20 and SOLR-30 and would like to use
> StAX as underlying parser.

+1 for StAX as the default XML parser.
For a general Java client though, I'd try and make it flexible enough
to get at the underlying data stream so someone could use another
parser if they so desire (or different syntaxes such as JSON).

-Yonik
Reply | Threaded
Open this post in threaded view
|

Re: preferred xml parser

Thorsten Scherler-3
On Wed, 2006-12-20 at 10:18 -0500, Yonik Seeley wrote:

> On 12/20/06, Thorsten Scherler
> <[hidden email]> wrote:
> > looking at the source code I wonder whether we have a preferred xml
> > parser model?
> >
> > I mean I can find:
> > - pull parsing
> > - DOM
> > - JDOM (at least in some jira patches)
>
> IMO, DOM & xpath is good for config.  xpath is easy, flexible and less
> error prone, and we aren't concerned with performance for reading
> config.

Agree, for the config.

>
> Pull parsing (StAX) for anything performance critical.
>
> XPP was used at the start, but I think there is a longer term plan to
> go with StAX.
> http://www.nabble.com/XPP-license-tf1468633.html#a3977357
>

ok

> > SAX I have not seen yet and neither StAX. I made some very good
> > experience with StAX lately it is fast and easy to use.
> >
> > Do we plan to recommend one technique (at least for the core)?
> > Do we have plans to create an interface for a SolrDocumentFactory? This
> > way we could have various underlying implementation returning always the
> > same: xml.
> >
> > I ask because I may look into SOLR-20 and SOLR-30 and would like to use
> > StAX as underlying parser.
>
> +1 for StAX as the default XML parser.
> For a general Java client though, I'd try and make it flexible enough
> to get at the underlying data stream so someone could use another
> parser if they so desire (or different syntaxes such as JSON).

I will think of something. I reckon an good defined interface will do
and I would provide the default implementation based on StAX.

Cheers for the feedback.

salu2

>
> -Yonik