Hi Yonik, Thanks. Replies below:
> My gut feeling is that we should not be introducing namespaces by default. > It introduces a new requirement of XML parsers in clients, and some > parsers would start validating by default, and going out to the web to > retrieve the referenced namespace/schema, etc. How does it introduce any new requirements? Namespaces are easily ignored by any XML client as they are if they weren't present. In other words, unless the XML client has setValidating=true, then this isn't an issue. Even if it does, then as long as namespaces are valid (which the source code for SOLR should have), then there wouldn't be anything introduced. So, basically the jist of it is, there are 0 new requirements introduced by this. There is only added functionality, if you want to use it. > > I think the initial geosearch feature can start off with > <str>10,20</str> for a point. > If we wish to introduce a point type in the XML and binary response > writers at a later point in time, it seems like it might require a > version bump of the output format anyway, and we could go to something > simple like <point>10,20</point>. The only difference between what you call simple above and what I've proposed (and correct me if I'm wrong but others have too) is that your <point tag would include a namespace prefix and an xmlns attribute. What's the difference? > > It is worth using standards when they buy you enough.... I'm not sure > this is one of those times. > I'm sure there are standards for numeric types like <int> too... but > using namespaces for that seems like overkill. There's a difference between a primitive type like int, and one like point. Also, it all comes down to your use case. If the only thing you're ever going to do with SOLR is have a SOLR client talk to it (Java, Ruby, whatever PL you want) then namespaces/etc. might be overkill. But why open up the response format then and advertise SOLR as something that provides REST-ful services for search? If that's the case, then users consuming those responses need the flexibility to customize them for their use case (validation, plugging into external GIS tools, etc.). So, I don't agree with this. > > But if someone wants to supply patches that can optionally enable > sticking in schema, namespaces, etc, w/o significant impact to the > default, that's OK too. Or perhaps a custom response writer that uses > namespaces for every single type for those who want that. All I've done is use what already exists. There doesn't need to be any patches. XmlWriter#writePrim allowed you to do this before, see: http://www.lucidimagination.com/search/document/be6fb7ce53c2922d/jira_create d_solr_1592_refactor_xmlwriter_starttag_to_allow_arbitrary_attributes_to_be_ writ _and_ XmlWriter#writeCdata does now as well. 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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
