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 Thanks, Paul Ramirez On 12/9/09 5:30 AM, "Grant Ingersoll" <gsing...@apache.org> 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 georss.org 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. Thoughts? -Grant
