lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (388J)" <chris.a.mattm...@jpl.nasa.gov>
Subject Re: Namespaces in response (SOLR-1586)
Date Wed, 09 Dec 2009 17:40:16 GMT
Hi Yonik,

> 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>

Sure, of course it does. It's because that's not valid XML syntax. You have
to declare the namespace for zoo. You can do it at the top of the XML file
in the root XML tag. Or, you can do it inline (like I've done in SOLR).

Try this:

<foo>
 <zoo:bar xmlns:zoo="http://example.com/zoo">hi</zoo:bar>
</foo>

Cheers,
Chris


> 
> 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
> <yonik@lucidimagination.com> wrote:
>> On Wed, Dec 9, 2009 at 11:44 AM, Mattmann, Chris A (388J)
>> <chris.a.mattmann@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
>> 
> 


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department University of
Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++



Mime
View raw message