: > : I think the initial geosearch feature can start off with : > : <str>10,20</str> for a point. : > : > +1. : : Fundamentally, how is a string a point?
Fundementally a string is not a point, and a point is not a string -- but if you want express the concept of a point in a manner that only uses very simple primative types, then a string containing comma seperated numbers is a pretty dencet way to do it. If you'd prefer, a pair of numbers would workd just as well... <arr><float>10</float><float>20</float></arr> : > The current XML format SOlr uses was designed to be extremely simple, very : > JSON-esque, and easily parsable by *anyone* in any langauge, without : > needing special knowledge of types . : : Whoah. I'm totally confused now. Why have FieldTypes then? When not just use : Lucene? The use case for FieldTypes is _not_ just for indexing, or querying. : It's also for representation? No, actually the use case for FieldTYpes is entirely about the internal logic of how Solr should deal with those fields, and how various operations should work on them. FieldTypes can dictate the internal representation within the confines of a Lucene index, but they should not circumvent the contracts of the response writers in dictating what is/isn't a legal response. XMLWriter.writePrim may be public, which means there is a loophole that plugin writers can exploit to add new tag names to the Solr XML response that violate the contract (and no we don't have a formal XSD or DTD for our XML response format, but we still have a very well advertised contract) -- but that doesn't mean that code which ships with Solr should exploit those loopholes to violate that contract. People should expect that if they use Solr as is without any custom code that the XMLResponseWriter won't all of the sudden start including new, non-primitive-ish, XML tags/attributes that weren't there before. That's the entire point of the format as it was designed: break down whatever complex data might be involved in a response into easily digestible maps/lists of maps/lists of very primitive types that can easily be used in any programming langauge. : allowed for a while I think), why prevent it? Allowing namespaces does _not_ : break anything. ... : > introducing a new 'point" concept, wether as <point> or as : > <georss:point/>, is going to break things for people. : : Show me an example, I fundamentally disagree with this. Ok. Let's start with SolrJ then: take a look at the KnownType enum (line 151) in XMLResponseParser... http://svn.apache.org/viewvc/lucene/solr/trunk/src/solrj/org/apache/solr/client/solrj/impl/XMLResponseParser.java?revision=819403&view=markup ...or let's do a random google code search for "solr xml lst" -- check out ResponseContentHandler in solrpy... http://code.google.com/p/solrpy/source/browse/trunk/solr/core.py#841 ...I can't write python code to save my life, but I have pretty good idea what that code will do if it sees an unexpected tag. This is how a *LOT* of SOlr client libraries are implemented ... it's not an issue of broken XML parsers freaking out about namespaces, it's an issue of having a long standing, heavily advertised "schema" for the XML response that promises to only ever use a handful of types. Adding any new tags to this format (regardless of how easy it may be because of that stupid fucking "public" modifier on XMLWuiter.writePrim) will absolutely break things for people. : And why is that? Isn't the point of SOLR to expand to use cases brought up : by users of the system? As long as those use cases can be principally : supported, without breaking backwards compatibility (or in that case, if : they do, with large blinking red text that says it), then you're shutting : people out for 0 benefit? It's aesthetics we're talking about here. I don't know if i'd say that's the point of Solr, but yes we should absolutely try to grow the capabilities of the system as new use cases come along. I am 100% in agreement that the existing "simple" XMLRresponseWriter is not for everyone -- Historicly we've tried to maintain a sense of equality between all of hte Response writers, so that they all contained the same data just with different markup -- but there are clearly cases where it would be nice to have a response writer that is allowed to "know more" about teh real structure of the data and represent it in a manner that more closely represents it's purpose. This was the entire point behind adding FieldType.toOBject, and UUIDFIeld w/the BinaryResponseWriter is a good example of the model we should follow in the future. There is a clear push for Solr to natively be able to generated responses that incorporate more "industry standard" XML schemas, and i would love to see us start adding functionality to do that, but bastardizing the existing XMLResponseWriter format is not the way to do it. Bottom Line: I am a big fat -1 on any patch to Solr that adds new xml tags to the output generated by the XMLResponseWriter. Feel free to call me stubborn, call me obstinant, call me pedantic -- but there is no way in hell i'm going to support a patch that does that. -Hoss