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 14:33:27 GMT
Hi Grant, and others,

My 2 cents (and of course I'm bias having prepared the patch):

> In SOLR-1586, the proposed patch introduces the concept that a Solr response
> can declare a namespace for part of the response (in this case, it is using
> the tags defined by to specify a point, etc.).

The patch doesn't introduce this concept -- it makes use of it.
XMLWriter#writePrim took care of that for me, see Hostetter's comment:

Since that method is public, anyone could have done this in the past, they
just chose not to. Moreover, they chose not to in the committed source for
SOLR, but others who took SOLR, prepared their own XML response writers,
etc., may have done this same thing as well.

> Discussion points:
> 1. If there are standard namespaces, then people can use them to do fun XML
> things

+1. This includes things like validation, strong typing (see SOLR-912 for
others who also believe that the NamedList BagOfObjects structure, while
robust, introduces type confusion when unraveling the response), and
plugging in to other tools. Imagine a GIS tool that required a
"georss:point" to be returned back somehow. You could argue XSLT could do
this, but as you note below, it's an extra step. It also _implicitly_ ties
the representation and typing of a FieldType to something that isn't really
tied to a field type at all (an XSLT file?)

> 2. If we allow them, we get all of the other benefits of namespaces...

For sure -- see above for some examples.

> 3. The indexing side doesn't support them, so it seems odd to put in something
> like <field name="point">55.3 27.9</field> and get back <georss:point
> name="point"> 55.3 27.9</georss:point>.  At the same time, it seems equally
> weird to get back <str name="point">...</str> when there is in fact more
> semantic information available about this particular field that would
> otherwise require more work by an application to make sense of.

You got it. I'm not sure why it seems weird -- the translation from
docs/fields to external representation (via response writers or field type
representation) is one of the benefits of SOLR IMHO.

> 4. If we let in other namespaces, we then are opening ourselves to longer
> responses, etc.  It is also likely the case that there isn't just one
> standard.  This likely could mean slower responses, etc.

How does adding in some characters (e.g., an "ns" tag and an associated URL)
add anything other than noise? We're talking the difference between O(n)
versus O(n+20) here. Also it's perfectly legit IMHO to say, well if you
introduce 10, 000 namespaces, well, that's on you, and be prepared for
slower client/server interactions.

> 5. If people wanted them, they could just do XSLT, but that is an extra step
> too.

Yep, that's an extra step, and it's not explicit, like the patch I attached
is. I tried to take advantage of one of SOLR's extension points in the
architecture to explicitly tie a representation of a Field to its external
and internal representation (aka, the point of a FieldType, no?)
> An alternative is that we could refactor things a bit and allow the FieldType
> to specify the tag name instead of it being hardcoded in the writers.  This
> way people writing FieldTypes could define them.  For instance, we could have
> FieldType.getTagName() that could be overridden and clients could have tools
> for introspecting this.

This is basically what I did right? I did an inline namespace using a
variant of #writePrm in XMLWriter (#writeCdata) and had the
FieldType#toExternal method set the tag name, which is allowed by the API.


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