Hi Yonik, > > I've run across cases where I added a schema declaration to an XML > file and then things started failing. I think some parsers may > default to validating if it sees that it can?
I've seen this too. But it won't affect the interaction we're talking about like I said, SOLR-1586 outputs valid XML, so this isn't an issue. > > Namespaces are to avoid name clashes. Solr XML is well defined and > not arbitrary... adding <point> if we wish to do so won't introduce > any clashes. > Actually there are quite a bit of use cases for namespacing beyond name clashes. Namespaces enable validation, understanding and definition for elements (understanding units, ranges, etc.). For instance, you and I both use the term "mass", but in my domain, mass refers to the planetary science definition of mass, but, in your domain you mean earth science. "mass" does not always mean the same thing (variation in units, representation, etc.) See here: http://www.w3.org/TR/2006/REC-xml-names11-20060816/ >> 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? > > REST-ful doesn't say anything about customizing the response format. So are you saying that the intention is not to allow customization of the response format? Also you've released how many releases of SOLR that have the capability to do this and now you're suddenly going to change it? I'm sorry I disagree. > >> 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. > > What GIS tool could deal with a Solr XML response format w/o any other > knowledge of everything else in the response? > Are there some real use cases that using a namespace vs not for point > make easier (an honest question... I don't know much about GIS stuff). Using standards enables standard tool development. Unless you want everyone to develop their own custom tools for SOLR (or be tied to using whatever is provided by SOLR _only_), and I don't think that's the intent. I also don't think that's a very friendly, open strategy for users. What I'm proposing does _not_ break backwards compatibility, anywhere. If you've got an example, then speak up. > >> 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: > > Yeah, you can use that to output <long>false</long> too... but it will > cause certain clients to barf. That's a ResponseWriter issue. That's not a client issue. Clients don't arbitrarily connect to servers for which they don't speak the protocol language. 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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
