lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (388J)" <>
Subject Re: Namespaces in response (SOLR-1586)
Date Wed, 09 Dec 2009 16:44:28 GMT
Hi Yonik,

Thanks. Replies below:

> My gut feeling is that we should not be introducing namespaces by default.
> It introduces a new requirement of XML parsers in clients, and some
> parsers would start validating by default, and going out to the web to
> retrieve the referenced namespace/schema, etc.

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. Even if it
does, then as long as namespaces are valid (which the source code for SOLR
should have), then there wouldn't be anything introduced.

So, basically the jist of it is, there are 0 new requirements introduced by
this. There is only added functionality, if you want to use it.

> I think the initial geosearch feature can start off with
> <str>10,20</str> for a point.
> If we wish to introduce a point type in the XML and binary response
> writers at a later point in time, it seems like it might require a
> version bump of the output format anyway, and we could go to something
> simple like <point>10,20</point>.

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

> But if someone wants to supply patches that can optionally enable
> sticking in schema, namespaces, etc, w/o significant impact to the
> default, that's OK too.  Or perhaps a custom response writer that uses
> namespaces for every single type for those who want that.

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:

_and_ XmlWriter#writeCdata does now as well.


Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Adjunct Assistant Professor, Computer Science Department University of
Southern California, Los Angeles, CA 90089 USA

View raw message