Hi Grant, and others, My 2 cents (and of course I'm bias having prepared the patch):
> 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.). The patch doesn't introduce this concept -- it makes use of it. XMLWriter#writePrim took care of that for me, see Hostetter's comment: http://www.lucidimagination.com/search/document/be6fb7ce53c2922d/jira_create d_solr_1592_refactor_xmlwriter_starttag_to_allow_arbitrary_attributes_to_be_ writ Since that method is public, anyone could have done this in the past, they just chose not to. Moreover, they chose not to in the committed source for SOLR, but others who took SOLR, prepared their own XML response writers, etc., may have done this same thing as well. > > Discussion points: > 1. If there are standard namespaces, then people can use them to do fun XML > things +1. This includes things like validation, strong typing (see SOLR-912 for others who also believe that the NamedList BagOfObjects structure, while robust, introduces type confusion when unraveling the response), and plugging in to other tools. Imagine a GIS tool that required a "georss:point" to be returned back somehow. You could argue XSLT could do this, but as you note below, it's an extra step. It also _implicitly_ ties the representation and typing of a FieldType to something that isn't really tied to a field type at all (an XSLT file?) > 2. If we allow them, we get all of the other benefits of namespaces... For sure -- see above for some examples. > 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. You got it. I'm not sure why it seems weird -- the translation from docs/fields to external representation (via response writers or field type representation) is one of the benefits of SOLR IMHO. > 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. How does adding in some characters (e.g., an "ns" tag and an associated URL) add anything other than noise? We're talking the difference between O(n) versus O(n+20) here. Also it's perfectly legit IMHO to say, well if you introduce 10, 000 namespaces, well, that's on you, and be prepared for slower client/server interactions. > 5. If people wanted them, they could just do XSLT, but that is an extra step > too. Yep, that's an extra step, and it's not explicit, like the patch I attached is. I tried to take advantage of one of SOLR's extension points in the architecture to explicitly tie a representation of a Field to its external and internal representation (aka, the point of a FieldType, no?) > > 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. This is basically what I did right? I did an inline namespace using a variant of #writePrm in XMLWriter (#writeCdata) and had the FieldType#toExternal method set the tag name, which is allowed by the API. Cheers, Chris ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.mattm...@jpl.nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
