: eh ... agree to disagree i guess. it seems just as valid to say that
: UpdateCommand -- what type of data does it update? ... or that
: RequestHandler is ambigious because it can only handle Solr requests,
: so it should be title SolrRequestHandler.
:
: True! I guess it's just aesthetics.
: a SolrQueryResponse, no one has ever accused any of those response writers
: of not being flexible enough to generate a *different* type of response in
: those formats.
:
: You may be right, but actually quite a few issues have referenced even non
: XMLWriters of similar issues. See:
I
Hi Hoss:
On 12/15/09 6:39 PM, Chris Hostetter hossman_luc...@fucit.org wrote:
: a SolrQueryResponse, no one has ever accused any of those response writers
: of not being flexible enough to generate a *different* type of response in
: those formats.
:
: You may be right, but actually
: I'm conflicted here. In simple semantics, sure it's just an array of
: float/double numbers. A, if a string must be used a comma is probably OK, so
: long as it maps to some existing known approach to represent points. I've
: asked several times if there are examples. I can point to one that
Hi Hoss,
On 12/14/09 3:18 PM, Chris Hostetter hossman_luc...@fucit.org wrote:
: Well, I actually would disagree. What's the point of #toInternal and
: #toExternal then, other than to convert from the external representation to
: an internal Lucene index representation, and then to do the
: : I think the initial geosearch feature can start off with
: : str10,20/str for a point.
:
: +1.
:
: Fundamentally, how is a string a point?
Fundementally a string is not a point, and a point is not a string -- but
if you want express the concept of a point in a manner that only uses
: themselves ... because of the back-ass-wards way we have FieldTypes write
: their values directly to an XMLWriter or a TextWriter the idea of using an
: object that stringifies itself as needed doesn't really apply very well
:
: I think it's rather powerful. You insulate the following
Hi Hoss,
: : I think the initial geosearch feature can start off with
: : str10,20/str for a point.
:
: +1.
:
: Fundamentally, how is a string a point?
Fundementally a string is not a point, and a point is not a string -- but
if you want express the concept of a point in a manner
Hi Hoss,
: I think it's rather powerful. You insulate the following variations into 1
: single place to change them (FieldType):
:
: * output representation
: * indexing
: * validation
:
: To remove this from FieldType would be to strew the same functionality
: across multiple classes,
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 georss.org to specify a point, etc.). I'm not sure what to
make of this. My gut reaction says no, but I'm not a
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 georss.org to specify a point,
Inline...
On Dec 9, 2009, at 9:33 AM, Mattmann, Chris A (388J) wrote:
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
Hi Grant,
My replies inline 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,
Yeah, but the rest of Solr's response doesn't have it, so...
You mean the rest of SOLR's default
Hey All,
1. Namespaces are fun especially when you have some target format you are
trying to work towards. Many target formats use namespaces extensively so
having the ability to map to them on the back end (response) would be great.
This does not mean that Solr would have to utilize
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.
I think the initial geosearch
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
Should have tried this before... I just created a small XML file:
foo
barhi/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:barhi/zoo:bar
/foo
That made both of them barf.
That alone makes me lean pretty strongly
Hi Yonik,
Should have tried this before... I just created a small XML file:
foo
barhi/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:barhi/zoo:bar
/foo
Sure, of course it does. It's because that's not
On Wed, Dec 9, 2009 at 12:40 PM, Mattmann, Chris A (388J)
chris.a.mattm...@jpl.nasa.gov wrote:
foo
zoo:bar xmlns:zoo=http://example.com/zoo;hi/zoo:bar
/foo
If you're forced to declare the namespace / put the URI, I'm just
afraid of what clients / XML parsers out there may start trying to
: I think the initial geosearch feature can start off with
: str10,20/str for a point.
+1.
The current XML format SOlr uses was designed to be extremely simple, very
JSON-esque, and easily parsable by *anyone* in any langauge, without
needing special knowledge of types . It has been heavily
: ...unless things have changed since hte last time i looked, all of the
: out of the box response writers call toString() on any object they
: don't understand. So the best way to move forward in a flexible manner
: seems like it would be to add a new GeoPoint object to Solr, which
:
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
Any parser that does that is so broken that you should stop using it
immediately. --wunder
Walter, totally agree here.
Cheers,
Chris
++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA
Hey All,
I think Eric is right on here and what I thought the intent of the patch was.
Facilitating integration of Solr into environments where there is not one true
XML output. In addition, there shouldn't be one true JSON output for cases
where your existing code already has a way it expects
On Dec 9, 2009, at 11:11 AM, Mattmann, Chris A (388J) wrote:
Any parser that does that is so broken that you should stop using it
immediately. --wunder
Walter, totally agree here.
To elaborate my position:
1. Validation is a user option. The XML spec makes that very clear. We've had
10
Hi Yonik,
Using standards enables standard tool development.
We do use standards... lots of them :-) Let's be a bit more specific
though - I was asking about using a namespace for the point type by
*default*, and in isolation (i.e. the rest of solr xml isn't
namespaced), and if/how that
26 matches
Mail list logo
