lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ramirez, Paul M (388J)" <>
Subject Re: Namespaces in response (SOLR-1586)
Date Wed, 09 Dec 2009 16:09:58 GMT
Hey All,

 1.  Namespaces are fun especially when you have some target format you are trying to work
towards. Many target formats use namespaces extensively so having the ability to map to them
on the back end (response) would be great. This does not mean that Solr would have to utilize
namespaces at all and supporting them internally is a different issue. I think that was the
spirit of the original patch.
 2.  From what I'm gathering this is a discussion of whether Solr supports them internally.
Hopefully, there is a differentiation between internal/external namespace usage with Solr.
 3.  Why must the response dictate what is done internally within Solr?
 4.  Internally it would seem that these are just string mappings and how much impact would
there really be to writing out the response?
 5.  If the shift is just to have them use XSLT my guess would be that would cause a slower
response than direct mappings. This is solely my opinion as I have not done any tests but
NamedList -> XML -> XSLT would seem logically slower than NamedList-> (mapped) XML

Paul Ramirez

On 12/9/09 5:30 AM, "Grant Ingersoll" <> wrote:

In SOLR-1586, the proposed patch introduces the concept that a Solr response can declare a
namespace for part of the response (in this case, it is using the tags defined by
to specify a point, etc.).  I'm not sure what to make of this.  My gut reaction says no, but
I'm not a namespace expert and I also don't feel strongly about it.

Discussion points:
1. If there are standard namespaces, then people can use them to do fun XML things
2. If we allow them, we get all of the other benefits of namespaces...
3. The indexing side doesn't support them, so it seems odd to put in something like <field
name="point">55.3 27.9</field> and get back <georss:point name="point"> 55.3
27.9</georss:point>.  At the same time, it seems equally weird to get back <str name="point">...</str>
when there is in fact more semantic information available about this particular field that
would otherwise require more work by an application to make sense of.
4. If we let in other namespaces, we then are opening ourselves to longer responses, etc.
 It is also likely the case that there isn't just one standard.  This likely could mean slower
responses, etc.
5. If people wanted them, they could just do XSLT, but that is an extra step too.

An alternative is that we could refactor things a bit and allow the FieldType to specify the
tag name instead of it being hardcoded in the writers.  This way people writing FieldTypes
could define them.  For instance, we could have FieldType.getTagName() that could be overridden
and clients could have tools for introspecting this.

I'm not sure what effect any of this would have on downstream clients, either.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message