solr-convert.xsl: stupid question #158

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

solr-convert.xsl: stupid question #158

Naomi Dushay
I'm a little confused as to why the XML solr response is being  
converted via solr-response.xsl to a different XML format ... which is  
then processed by the code.  Couldn't the UI code work off the solr  
response XML directly?

Also, it is confusing that there are two solr-convert.xsl files

web/xsl
web/services/Search/xsl  <-- not used, I believe?


Naomi Dushay
[hidden email]




-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: solr-convert.xsl: stupid question #158

Andrew Nagy-2
Naomi - It is always good to question little things like this.  I think this is one of the reasons open source code is successful - if no one ever questions linus about his work - the linux kernel would probably not be much of a success :)

There is a long story for the use of the solr-convert.xsl file - I will try to sum it up.  I started developing vufind for php4 (php5 was available but not iron-clad).  I think PHP5.2 is pretty good now.  PHP4 had poor xml support, and I commonly used the PEAR::XML_Serializer package (and still do) for parsing XML.  It's very easy/convenient to use for small non-complex xml documents (you should see my xml_serializer METS writer - it might make you cry).  Still easier than PHP5's DOM package in some sense.  Probably not the most efficient/highest performance though.  To make the use of the XML_Serializer package - it works much faster when you don't need to parse xml attributes - I implemented the solr-convert.xsl file to remove any unnecessary content from being parsed as well as converting all attributes to subfields.

This process could probably be re-written using the DOM parser - but hey, it ain't broke at this point.  Solr also has a built in XSL engine, and the stylesheet could even be applied SOLR side rather than in the PHP, but my guess is there would be no difference.

Also - I think the solr response xml is a bit hokey.  Each list of content is in a "lst" tag.  At first glance, what the heck does lst mean?  Apparently it is an abbreviation for a 4 letter word.  If you look back in the solr list logs, you will see my first posting is a question as to why all of the main tags in the response xml is 1st (first) :).  If you use a courier type font lst and 1st look almost identical.  Im sure they have some reasoning for the design of their xml response - but it just doesn't make any sense to me.

As to the other solr-convert.xsl - I will remove that from SVN.

p.s.  Feel free to improve on any of this :)

Andrew

> -----Original Message-----
> From: [hidden email] [mailto:vufind-tech-
> [hidden email]] On Behalf Of Naomi Dushay
> Sent: Monday, July 14, 2008 1:54 PM
> To: [hidden email]
> Subject: [VuFind-Tech] solr-convert.xsl: stupid question #158
>
> I'm a little confused as to why the XML solr response is being
> converted via solr-response.xsl to a different XML format ... which is
> then processed by the code.  Couldn't the UI code work off the solr
> response XML directly?
>
> Also, it is confusing that there are two solr-convert.xsl files
>
> web/xsl
> web/services/Search/xsl  <-- not used, I believe?
>
>
> Naomi Dushay
> [hidden email]
>
>
>
>
> -----------------------------------------------------------------------
> --
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Vufind-tech mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/vufind-tech

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: solr-convert.xsl: stupid question #158

Naomi Dushay
Andrew,

Thanks for this explanation - it's very helpful.  I'm inclined to  
agree - it's not currently broken, so why fix it.

Believe it or not, I'm really trying to focus on the solrmarc import  
and the field definitions in the solr schema.  And I am hopeful of  
contributing some helpful fixes for those issues.

- Naomi

On Jul 14, 2008, at 11:13 AM, Andrew Nagy wrote:

> Naomi - It is always good to question little things like this.  I  
> think this is one of the reasons open source code is successful - if  
> no one ever questions linus about his work - the linux kernel would  
> probably not be much of a success :)
>
> There is a long story for the use of the solr-convert.xsl file - I  
> will try to sum it up.  I started developing vufind for php4 (php5  
> was available but not iron-clad).  I think PHP5.2 is pretty good  
> now.  PHP4 had poor xml support, and I commonly used the  
> PEAR::XML_Serializer package (and still do) for parsing XML.  It's  
> very easy/convenient to use for small non-complex xml documents (you  
> should see my xml_serializer METS writer - it might make you cry).  
> Still easier than PHP5's DOM package in some sense.  Probably not  
> the most efficient/highest performance though.  To make the use of  
> the XML_Serializer package - it works much faster when you don't  
> need to parse xml attributes - I implemented the solr-convert.xsl  
> file to remove any unnecessary content from being parsed as well as  
> converting all attributes to subfields.
>
> This process could probably be re-written using the DOM parser - but  
> hey, it ain't broke at this point.  Solr also has a built in XSL  
> engine, and the stylesheet could even be applied SOLR side rather  
> than in the PHP, but my guess is there would be no difference.
>
> Also - I think the solr response xml is a bit hokey.  Each list of  
> content is in a "lst" tag.  At first glance, what the heck does lst  
> mean?  Apparently it is an abbreviation for a 4 letter word.  If you  
> look back in the solr list logs, you will see my first posting is a  
> question as to why all of the main tags in the response xml is 1st  
> (first) :).  If you use a courier type font lst and 1st look almost  
> identical.  Im sure they have some reasoning for the design of their  
> xml response - but it just doesn't make any sense to me.
>
> As to the other solr-convert.xsl - I will remove that from SVN.
>
> p.s.  Feel free to improve on any of this :)
>
> Andrew
>
>> -----Original Message-----
>> From: [hidden email] [mailto:vufind-tech-
>> [hidden email]] On Behalf Of Naomi Dushay
>> Sent: Monday, July 14, 2008 1:54 PM
>> To: [hidden email]
>> Subject: [VuFind-Tech] solr-convert.xsl: stupid question #158
>>
>> I'm a little confused as to why the XML solr response is being
>> converted via solr-response.xsl to a different XML format ... which  
>> is
>> then processed by the code.  Couldn't the UI code work off the solr
>> response XML directly?
>>
>> Also, it is confusing that there are two solr-convert.xsl files
>>
>> web/xsl
>> web/services/Search/xsl  <-- not used, I believe?
>>
>>
>> Naomi Dushay
>> [hidden email]
>>
>>
>>
>>
>> -----------------------------------------------------------------------
>> --
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic  
>> lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> _______________________________________________
>> Vufind-tech mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/vufind-tech

Naomi Dushay
[hidden email]




-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech