: I'm conflicted here. In simple semantics, sure it's just an array of : float/double numbers. A, if a string must be used a comma is probably OK, so : long as it maps to some existing known approach to represent points. I've : asked several times if there are examples. I can point to one that uses : spaces to separate the coordinates in the point (georss). What others use : comma?
I have no opinion about the details ... space seperated string, comma seperated string, list of ints ... they are all the same to me. As a layman, my limited knowledge of geo coordinates has a vague notion that comma is the seperated used when discussing latitude nad longitute, but i have no real knowledge of naything GIS related. (i think i remember that KML uses comma, but KML also has some weird idea that longitude comes first because that's what the guys writing graphics rendering engines aparently like: y-axis first) : Well, I actually would disagree. What's the point of #toInternal and : #toExternal then, other than to convert from the external representation to : an internal Lucene index representation, and then to do the opposite coming : out of the index? that is what they are for -- but they deal purely in string representations of hte data itself -- they don't (and shouldn't) know/care wether the data is then being encapsulted in JSON, thrift, Avro, Solr XML, RSS, KML, etc.... The "String" limitation of toExternal is on of the reasons toObject was added (and the reason the BinaryResponseWRiter uses toObject()). : class final which it once was). We should rename that to : SolrXmlResponseWriter, but it's not really generic XML (as the name : suggests), it's SOLR's custom (undocumented) XML schema, right? Also, since Eh... i don't know that the name suggests that it can generate generic XML, it generates a (particular) one to one mapping from the SolrQueryResponse to XML .. just like the JSONResponseWriter generates a one to one mapping fromthe SolrQueryResponse to JSON, and ditoo for the ruby/php/python writers ... there an infinite number of possible XML/JSON/Ruby/PHP/Python/etc. structures that *could* be generated from a SolrQueryResponse, no one has ever accused any of those response writers of not being flexible enough to generate a *different* type of response in those formats. And practicle speaking: slapping "Solr" in front of a response writer classname isn't going to make it crystal clear that it produces a "solr specific" type of "____". It's oging to make people think it's the "Solr" implemntation of "____". "Solr" is hte prefix of enough classnames that eyeballs are just going to gloss over it. : suggests), it's SOLR's custom (undocumented) XML schema, right? Also, since : it's undocumented, I'd be happy to throw it together for it's XML format. we actaully went round and round on documenting it back in the early days .. frequently it was deemed "self documenting" enough for end users so not much effort was ever put into it. there was a Jira issue to create and XSD, but even once we had one, no one really had any idea what to *do* with it... https://issues.apache.org/jira/browse/SOLR-17 : Would that also be welcomed? Then, we should develop an easy extension point : mechanism for people who want to develop their own XML response writers and : write their own clients (or leverage existing clients that understand that : XML). +1 I think the crux of this would be XML based response writer similar to hte BinaryResponseWriter that can use a "codec" type system for outputing known types of objects, using FiledType.toOBject() to get field values. Then we just have to provide "default" codecs for all the types of objects we produce "out of the box", but people can customize with their own codecs if they want differnet representation. -Hoss
