Should have tried this before... I just created a small XML file: <foo> <bar>hi</bar> </foo>
I pointed both firefox and IE at this file and it displays as XML fine. I then changed the file to this: <foo> <zoo:bar>hi</zoo:bar> </foo> That made both of them barf. That alone makes me lean pretty strongly against using a namespace for this. -Yonik http://www.lucidimagination.com On Wed, Dec 9, 2009 at 12:28 PM, Yonik Seeley <yo...@lucidimagination.com> wrote: > On Wed, Dec 9, 2009 at 11:44 AM, Mattmann, Chris A (388J) > <chris.a.mattm...@jpl.nasa.gov> wrote: >> 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. > > 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? > > 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. > >> 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. > >> 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). > >> 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. > > -Yonik > http://www.lucidimagination.com >
