Solr
  1. Solr
  2. SOLR-17

XSD for solr requests/responses

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      Attaching an XML schema definition for the responses and the update requests. I needed to do this for myself anyway, so I might as well contribute it to the project.

      At the moment, I have no plans to write an XSD for the config documents, but it wouldn't be a bad idea.

      TODO: change the schema URL. I'm guessing that Apache already has some sort of naming convention for these?

      1. solr.xsd
        6 kB
        Mike Baranczak
      2. UselessRequestHandler.java
        2 kB
        Hoss Man
      3. solr-complex.xml
        4 kB
        Hoss Man
      4. solr-rev2.xsd
        8 kB
        Mike Baranczak
      5. SOLR-17.Mattmann.121709.patch.txt
        17 kB
        Chris A. Mattmann

        Issue Links

          Activity

          Hide
          Hoss Man added a comment -

          This looks like it should work for the default behavior of the StandardRequestHandler ... but it doesn't look like it can deal with debugQuery=1, or any of the complex types of data that can be returned by other request handlers.

          if we commit an XSD, it should be able to handle anything that's legal for XmlOutputWriter to produce.

          I'll attach an example of a crazy handler with all sorts of weird behavior that can be used as a sanity test of an XSD.

          Show
          Hoss Man added a comment - This looks like it should work for the default behavior of the StandardRequestHandler ... but it doesn't look like it can deal with debugQuery=1, or any of the complex types of data that can be returned by other request handlers. if we commit an XSD, it should be able to handle anything that's legal for XmlOutputWriter to produce. I'll attach an example of a crazy handler with all sorts of weird behavior that can be used as a sanity test of an XSD.
          Hide
          Hoss Man added a comment -

          really crazy handler, and an example of the output it produces using the example index.

          Show
          Hoss Man added a comment - really crazy handler, and an example of the output it produces using the example index.
          Hide
          Mike Baranczak added a comment -

          Just one question. What's the difference between a 'lst' and an 'arr'? From what I can see in the enclosed sample, they both behave the same way.

          Show
          Mike Baranczak added a comment - Just one question. What's the difference between a 'lst' and an 'arr'? From what I can see in the enclosed sample, they both behave the same way.
          Hide
          Hoss Man added a comment -

          <lst> is created for Maps and NamedLists, <arr> is created for Arrays and regular Lists (possibly Set too, but i'm not sure)

          The big distinction is that the objects contained in a <lst> may have names, the objects contained in an <arr> will not.

          ...i think.

          Show
          Hoss Man added a comment - <lst> is created for Maps and NamedLists, <arr> is created for Arrays and regular Lists (possibly Set too, but i'm not sure) The big distinction is that the objects contained in a <lst> may have names, the objects contained in an <arr> will not. ...i think.
          Hide
          Mike Baranczak added a comment -

          Revised the XSD so that the crazy file validates.

          Show
          Mike Baranczak added a comment - Revised the XSD so that the crazy file validates.
          Hide
          Hoss Man added a comment -

          Very cool Mike, thanks a lot.

          I think there's one small thing missing though: <xs:complexType name="result"> should need an <xs:attribute name="name" type="xs:string"/> just like the other complexTypes since it can be added to the response (or to a Map or a NamedList) with a name right?

          all we have to do know is figure out what to do with this ... i'm sure you're right, there must be some standard naming convention/URL for DTDs and schemas ... i just don't know what it is.

          Show
          Hoss Man added a comment - Very cool Mike, thanks a lot. I think there's one small thing missing though: <xs:complexType name="result"> should need an <xs:attribute name="name" type="xs:string"/> just like the other complexTypes since it can be added to the response (or to a Map or a NamedList) with a name right? all we have to do know is figure out what to do with this ... i'm sure you're right, there must be some standard naming convention/URL for DTDs and schemas ... i just don't know what it is.
          Hide
          Hoss Man added a comment -

          Comment that came up regarding this issue in a solr-dev email today (Subj: "Re: XML and JSON input / output specs?"

          There was work done on an XSD file for the Solr output XML format, i think
          it was almost finished but it had a few kinks; and we weren't relaly sure
          what to do with it once we had it (maybe just include it in documentation
          and put a hook in AbstractSolrTest to validate all responses aginst it so
          we're sure we never break it)...

          Show
          Hoss Man added a comment - Comment that came up regarding this issue in a solr-dev email today (Subj: "Re: XML and JSON input / output specs?" There was work done on an XSD file for the Solr output XML format, i think it was almost finished but it had a few kinks; and we weren't relaly sure what to do with it once we had it (maybe just include it in documentation and put a hook in AbstractSolrTest to validate all responses aginst it so we're sure we never break it)...
          Hide
          Chris A. Mattmann added a comment -

          There are actually a lot of useful things that could be done with an XSD.

          For starters:

          1. we could have validated the the XML i wanted to introduce as part of SOLR-1586 wouldn't work automatically.
          2. we could generate a custom Solr XML Response Reader using JAXB
          3. we could generate sample Solr XML Responses with ease using a tool like Doxygen or XMLSpy
          Show
          Chris A. Mattmann added a comment - There are actually a lot of useful things that could be done with an XSD. For starters: we could have validated the the XML i wanted to introduce as part of SOLR-1586 wouldn't work automatically. we could generate a custom Solr XML Response Reader using JAXB we could generate sample Solr XML Responses with ease using a tool like Doxygen or XMLSpy
          Hide
          Shalin Shekhar Mangar added a comment -

          This is like a solution looking for a problem.

          Show
          Shalin Shekhar Mangar added a comment - This is like a solution looking for a problem.
          Hide
          Chris A. Mattmann added a comment -

          In what way? And furthermore, I don't appreciate the tone of your comment. Is this the way you, as a committer, encourage people to contribute to SOLR? I hope not.

          Show
          Chris A. Mattmann added a comment - In what way? And furthermore, I don't appreciate the tone of your comment. Is this the way you, as a committer, encourage people to contribute to SOLR? I hope not.
          Hide
          Shalin Shekhar Mangar added a comment -

          Chris, it seems that you are taking my comment personally. Please don't; it is not my intention to ridicule anyone's efforts.

          As you can see, this issue has been open for some time now and a major reason is that we have never found a good use for an XSD. I'm merely trying to say that it seems like we're trying to find use-cases for a solution instead of starting with an actual need.

          My point is that Solr can use it we want to but Solr certainly does not need to use it. I don't think we gain much by an XSD.

          Show
          Shalin Shekhar Mangar added a comment - Chris, it seems that you are taking my comment personally. Please don't; it is not my intention to ridicule anyone's efforts. As you can see, this issue has been open for some time now and a major reason is that we have never found a good use for an XSD. I'm merely trying to say that it seems like we're trying to find use-cases for a solution instead of starting with an actual need. My point is that Solr can use it we want to but Solr certainly does not need to use it. I don't think we gain much by an XSD.
          Hide
          Chris A. Mattmann added a comment -

          Chris, it seems that you are taking my comment personally. Please don't; it is not my intention to ridicule anyone's efforts.

          I wouldn't say I took it personally – as I said, I'm not sure I appreciated the tone of the comment. A one-liner, that's curt, provides no background (lest only an opinion), and that sounds like ridicule will elicit such a response in many cases, see Netiquette Guidelines:

          http://tools.ietf.org/html/rfc1855

          As you can see, this issue has been open for some time now and a major reason is that we have never found a good use for an XSD. I'm merely trying to say that it seems like we're trying to find use-cases for a solution instead of starting with an actual need.

          Sure, judging by its issue number (17), I could tell it has been open for a while. The ongoing conversation regarding SOLR-1586, see here:

          http://www.lucidimagination.com/search/document/7094af4a3aa8bc03/namespaces_in_response_solr_1586

          led me to this issue, as pointed out by Hoss. There have been some relevant discussions that have come up regarding XSD's, which was my point. So, I'm not sure that we're trying to find anything – the discussion presented itself on its own. Furthermore, even if the discussion hadn't occured, it doesn't seem very contribution friendly to ignore something that clearly adds value to a group of people. XML and XSD people exist and have their tools (as I noted above, Doxygen, XMLSpy, etc.) for doing validation, and for generating sample XML files, for designing XML, etc.. Just because there aren't a lot of votes on the issue, or lots of mail traffic, it doesn't mean that the issue should not get attention. I'm not sure what's so controversial about adding an XSD to the SOLR trunk. Hence my point in calling attention to this issue. There's been a patch available for quite some time. What's missing from the patch to get this contribution into the trunk?

          My point is that Solr can use it we want to but Solr certainly does not need to use it. I don't think we gain much by an XSD.

          I agree that SOLR, from a code/API/functionality perspective, does not need to use it. However, it would not hurt anything to add the XSD as part of the trunk for those that would like to download it and use it to understand how to write additional SOLR XML consuming clients. Or for those that would like to validate SOLR XML responses they receive. This isn't outside of the ordinary at all, and I think only adds value, and doesn't take any away. If the concern is maintaining it, I'd be happy to do so. I'm sure there are others that would contribute as well.

          Show
          Chris A. Mattmann added a comment - Chris, it seems that you are taking my comment personally. Please don't; it is not my intention to ridicule anyone's efforts. I wouldn't say I took it personally – as I said, I'm not sure I appreciated the tone of the comment. A one-liner, that's curt, provides no background (lest only an opinion), and that sounds like ridicule will elicit such a response in many cases, see Netiquette Guidelines: http://tools.ietf.org/html/rfc1855 As you can see, this issue has been open for some time now and a major reason is that we have never found a good use for an XSD. I'm merely trying to say that it seems like we're trying to find use-cases for a solution instead of starting with an actual need. Sure, judging by its issue number (17), I could tell it has been open for a while. The ongoing conversation regarding SOLR-1586 , see here: http://www.lucidimagination.com/search/document/7094af4a3aa8bc03/namespaces_in_response_solr_1586 led me to this issue, as pointed out by Hoss. There have been some relevant discussions that have come up regarding XSD's, which was my point. So, I'm not sure that we're trying to find anything – the discussion presented itself on its own. Furthermore, even if the discussion hadn't occured, it doesn't seem very contribution friendly to ignore something that clearly adds value to a group of people. XML and XSD people exist and have their tools (as I noted above, Doxygen, XMLSpy, etc.) for doing validation, and for generating sample XML files, for designing XML, etc.. Just because there aren't a lot of votes on the issue, or lots of mail traffic, it doesn't mean that the issue should not get attention. I'm not sure what's so controversial about adding an XSD to the SOLR trunk. Hence my point in calling attention to this issue. There's been a patch available for quite some time. What's missing from the patch to get this contribution into the trunk? My point is that Solr can use it we want to but Solr certainly does not need to use it. I don't think we gain much by an XSD. I agree that SOLR, from a code/API/functionality perspective, does not need to use it. However, it would not hurt anything to add the XSD as part of the trunk for those that would like to download it and use it to understand how to write additional SOLR XML consuming clients. Or for those that would like to validate SOLR XML responses they receive. This isn't outside of the ordinary at all, and I think only adds value, and doesn't take any away. If the concern is maintaining it, I'd be happy to do so. I'm sure there are others that would contribute as well.
          Hide
          Uri Boness added a comment -

          Having well defined XSD's for public services can be extremely helpful in many aspects... together with proper version management they define the contract between the users the the service. Some of the use cases that Chris listed above are definitely valid and realistic. Moreover, XSD provides a natural and proper documentation for the supported formats which any decent xml editor can make use of and provide you with hints for writing the solrconfig.xml and the schema.xml (for example).

          That said... most of the xml formats in Solr are too generic to benefit from XSD's. The only format where it makes sense is the schema.xml as it has an expressive domain-driven structure. Unfortunately this is something you cannot say for for the response formats and the solrconfig.xml where the expressiveness lays within the values of the elements/attributes rather than in the elements/attribute names themselves. XSD doesn't handle element/attribute values very well.

          Show
          Uri Boness added a comment - Having well defined XSD's for public services can be extremely helpful in many aspects... together with proper version management they define the contract between the users the the service. Some of the use cases that Chris listed above are definitely valid and realistic. Moreover, XSD provides a natural and proper documentation for the supported formats which any decent xml editor can make use of and provide you with hints for writing the solrconfig.xml and the schema.xml (for example). That said... most of the xml formats in Solr are too generic to benefit from XSD's. The only format where it makes sense is the schema.xml as it has an expressive domain-driven structure. Unfortunately this is something you cannot say for for the response formats and the solrconfig.xml where the expressiveness lays within the values of the elements/attributes rather than in the elements/attribute names themselves. XSD doesn't handle element/attribute values very well.
          Hide
          Chris A. Mattmann added a comment -

          Hi Uri:

          Thanks. Comments below:

          Having well defined XSD's for public services can be extremely helpful in many aspects... together with proper version management they define the contract between the users the the service. Some of the use cases that Chris listed above are definitely valid and realistic. Moreover, XSD provides a natural and proper documentation for the supported formats which any decent xml editor can make use of and provide you with hints for writing the solrconfig.xml and the schema.xml (for example).

          +1.

          That said... most of the xml formats in Solr are too generic to benefit from XSD's. The only format where it makes sense is the schema.xml as it has an expressive domain-driven structure. Unfortunately this is something you cannot say for for the response formats and the solrconfig.xml where the expressiveness lays within the values of the elements/attributes rather than in the elements/attribute names themselves. XSD doesn't handle element/attribute values very well.

          Kinda sorta. Regardless of how generic the XML used in SOLR is, I think it can still benefit from being documented in an XSD. That way, as you mentioned above, if it ever changes, with proper versioning, you have a baseline. In addition, for those wanting to know what can and can't be done to be a valid SOLR XML response (as I did w.r.t. geo stuff), the XSD/DTD can serve as a guide regarding that interface. And beyond just names, there's cardinality that the XSD could help validate (i.e., can you have sub-tags within a <double> in the SOLR XML response? – the answer is no, and this is something that could be codified in a DTD/XSD). Furthermore, we could also document what each of the valid attribute and element definitions are too, which would be useful even from a documentation perspective.

          Maybe the idea is that we should have XSD/DTDs for not only the services, but also for some of the configuration. This is a completely valid idea and I'm +1 for it. However, as a start, I think contributing and committing the SOLR XML response writer output XSD (and a DTD, which I'll attach) is something that adds value, doesn't take anything away, or touch other parts of the code, etc., and is worthwhile to do.

          Cheers,
          Chris

          Show
          Chris A. Mattmann added a comment - Hi Uri: Thanks. Comments below: Having well defined XSD's for public services can be extremely helpful in many aspects... together with proper version management they define the contract between the users the the service. Some of the use cases that Chris listed above are definitely valid and realistic. Moreover, XSD provides a natural and proper documentation for the supported formats which any decent xml editor can make use of and provide you with hints for writing the solrconfig.xml and the schema.xml (for example). +1. That said... most of the xml formats in Solr are too generic to benefit from XSD's. The only format where it makes sense is the schema.xml as it has an expressive domain-driven structure. Unfortunately this is something you cannot say for for the response formats and the solrconfig.xml where the expressiveness lays within the values of the elements/attributes rather than in the elements/attribute names themselves. XSD doesn't handle element/attribute values very well. Kinda sorta. Regardless of how generic the XML used in SOLR is, I think it can still benefit from being documented in an XSD. That way, as you mentioned above, if it ever changes, with proper versioning, you have a baseline. In addition, for those wanting to know what can and can't be done to be a valid SOLR XML response (as I did w.r.t. geo stuff), the XSD/DTD can serve as a guide regarding that interface. And beyond just names, there's cardinality that the XSD could help validate (i.e., can you have sub-tags within a <double> in the SOLR XML response? – the answer is no, and this is something that could be codified in a DTD/XSD). Furthermore, we could also document what each of the valid attribute and element definitions are too, which would be useful even from a documentation perspective. Maybe the idea is that we should have XSD/DTDs for not only the services, but also for some of the configuration. This is a completely valid idea and I'm +1 for it. However, as a start, I think contributing and committing the SOLR XML response writer output XSD (and a DTD, which I'll attach) is something that adds value, doesn't take anything away, or touch other parts of the code, etc., and is worthwhile to do. Cheers, Chris
          Hide
          Uri Boness added a comment -

          However, as a start, I think contributing and committing the SOLR XML response writer output XSD (and a DTD, which I'll attach) is something that adds value, doesn't take anything away, or touch other parts of the code, etc., and is worthwhile to do.

          Fair enough. I guess it can always serve as a reference to better understanding what to expect from a Solr response (instead of trying to figure things out from the code). Good thing about this generic format is that it's unlikely to change that frequently, so the XSD's will probably not change that often as well.

          Show
          Uri Boness added a comment - However, as a start, I think contributing and committing the SOLR XML response writer output XSD (and a DTD, which I'll attach) is something that adds value, doesn't take anything away, or touch other parts of the code, etc., and is worthwhile to do. Fair enough. I guess it can always serve as a reference to better understanding what to expect from a Solr response (instead of trying to figure things out from the code). Good thing about this generic format is that it's unlikely to change that frequently, so the XSD's will probably not change that often as well.
          Hide
          Hoss Man added a comment -

          There are actually a lot of useful things that could be done with an XSD.

          I agree ... my comment (way back when) was more about what we should do with it in a Solr release: converting it from a *.xsd attachment to a *.patch attachment...

          1. where should it live in source control? where should it live in the release artifact?
          2. what schema URI should we pick for identifying this? (i suspect apache.org has a standard for this, so or at least precident from other projects, so we should make sure we follow those examples before picking one arbitrarily
          3. it won't do any good unless we make the XmlResponseWriter refrence the schema URI so client tools can validate with it.
          4. we need hooks in our own test system for validating responses we get back to catch potential bugs (either in the schema itself, or in xml that might get inadvertantly changed)

          ...etc...

          Show
          Hoss Man added a comment - There are actually a lot of useful things that could be done with an XSD. I agree ... my comment (way back when) was more about what we should do with it in a Solr release: converting it from a *.xsd attachment to a *.patch attachment... 1. where should it live in source control? where should it live in the release artifact? 2. what schema URI should we pick for identifying this? (i suspect apache.org has a standard for this, so or at least precident from other projects, so we should make sure we follow those examples before picking one arbitrarily 3. it won't do any good unless we make the XmlResponseWriter refrence the schema URI so client tools can validate with it. 4. we need hooks in our own test system for validating responses we get back to catch potential bugs (either in the schema itself, or in xml that might get inadvertantly changed) ...etc...
          Hide
          Chris A. Mattmann added a comment -

          @Uri:

          Fair enough. I guess it can always serve as a reference to better understanding what to expect from a Solr response (instead of trying to figure things out from the code). Good thing about this generic format is that it's unlikely to change that frequently, so the XSD's will probably not change that often as well.

          +1, thanks for hearing me out!

          @Hoss

          1. where should it live in source control? where should it live in the release artifact?
          2. what schema URI should we pick for identifying this? (i suspect apache.org has a standard for this, so or at least precident from other projects, so we should make sure we follow those examples before picking one arbitrarily

          In src, I think it should live here: src/xsd (let's call it solrresponse.xsd), and let's make a DTD too (called solrresponse.dtd) that lives in src/dtd. In release, let's make it live somewhere that gets published onto the SOLR website (you guys are using forrest, right? I can put a patch together that copies it to the right place). It would be great to have it at, say:

          http://lucene.apache.org/solr/schema/solrresponse.xsd
          http://lucene.apaceh.org/solr/dtd/solrresponse.dtd

          In the long term, maybe we could version the URIs too, based on the current SOLR version, but that's down the road.

          3. it won't do any good unless we make the XmlResponseWriter refrence the schema URI so client tools can validate with it.

          Well it'll do some good just to have it out there. I'm a fan of incremental patchiness, so as a start, can we make this issue just put the XSD/DTD into the src, and then copy it to a Forrest accessible link, and then a do site rebuild? Then, as patch #2, we tackle your #3 above. I agree, #3 is pretty trivial (modifying a static final String in XMLWriter.java), but to me we can do it as a separate, clean patch, not cluttered with adding the XSD/DTD and then modifying Forrest (which this patch can do).

          4. we need hooks in our own test system for validating responses we get back to catch potential bugs (either in the schema itself, or in xml that might get inadvertantly changed)

          I think this is patch #3, or maybe #2a (and can go in along with #2 above), but +1 for this too. I'm happy to contribute/lead the efforts here. I'll start preparing patches right away.

          Cheers,
          Chris

          Show
          Chris A. Mattmann added a comment - @Uri: Fair enough. I guess it can always serve as a reference to better understanding what to expect from a Solr response (instead of trying to figure things out from the code). Good thing about this generic format is that it's unlikely to change that frequently, so the XSD's will probably not change that often as well. +1, thanks for hearing me out! @Hoss 1. where should it live in source control? where should it live in the release artifact? 2. what schema URI should we pick for identifying this? (i suspect apache.org has a standard for this, so or at least precident from other projects, so we should make sure we follow those examples before picking one arbitrarily In src, I think it should live here: src/xsd (let's call it solrresponse.xsd), and let's make a DTD too (called solrresponse.dtd) that lives in src/dtd. In release, let's make it live somewhere that gets published onto the SOLR website (you guys are using forrest, right? I can put a patch together that copies it to the right place). It would be great to have it at, say: http://lucene.apache.org/solr/schema/solrresponse.xsd http://lucene.apaceh.org/solr/dtd/solrresponse.dtd In the long term, maybe we could version the URIs too, based on the current SOLR version, but that's down the road. 3. it won't do any good unless we make the XmlResponseWriter refrence the schema URI so client tools can validate with it. Well it'll do some good just to have it out there. I'm a fan of incremental patchiness, so as a start, can we make this issue just put the XSD/DTD into the src, and then copy it to a Forrest accessible link, and then a do site rebuild? Then, as patch #2, we tackle your #3 above. I agree, #3 is pretty trivial (modifying a static final String in XMLWriter.java), but to me we can do it as a separate, clean patch, not cluttered with adding the XSD/DTD and then modifying Forrest (which this patch can do). 4. we need hooks in our own test system for validating responses we get back to catch potential bugs (either in the schema itself, or in xml that might get inadvertantly changed) I think this is patch #3, or maybe #2a (and can go in along with #2 above), but +1 for this too. I'm happy to contribute/lead the efforts here. I'll start preparing patches right away. Cheers, Chris
          Hide
          Chris A. Mattmann added a comment -

          Patch that implements step 1 of the 3 step process I outlined at the bottom of the comments in this task. I'll create JIRA issues for the other 2 right now. My +1 for getting this in. Thanks.

          Show
          Chris A. Mattmann added a comment - Patch that implements step 1 of the 3 step process I outlined at the bottom of the comments in this task. I'll create JIRA issues for the other 2 right now. My +1 for getting this in. Thanks.
          Hide
          Chris A. Mattmann added a comment -

          Okay, patches attached (to this issue, and to SOLR-1669) and issues created (SOLR-1669 and SOLR-1671). I don't have one for SOLR-1671 yet, but could probably throw one together by next week. In the meanwhile, I think the patch for SOLR-17 and for SOLR-1669 are ready to go, so at least progress can be made there.

          Thanks!

          Show
          Chris A. Mattmann added a comment - Okay, patches attached (to this issue, and to SOLR-1669 ) and issues created ( SOLR-1669 and SOLR-1671 ). I don't have one for SOLR-1671 yet, but could probably throw one together by next week. In the meanwhile, I think the patch for SOLR-17 and for SOLR-1669 are ready to go, so at least progress can be made there. Thanks!
          Hide
          Noble Paul added a comment -

          the XSD in the latest patch looks wrong to me.

           <xs:complexType name="response">
                  <xs:sequence minOccurs="0">
                      <xs:element name="responseHeader" type="responseHeader" minOccurs="1"/>
                      <xs:choice minOccurs="0" maxOccurs="unbounded">
                          <xs:element name="result" type="result"/>
          

          response does not contain a tag called "responseHeader" or an attribute called "status". so there is no type called "responseHeader".

          Show
          Noble Paul added a comment - the XSD in the latest patch looks wrong to me. <xs:complexType name= "response" > <xs:sequence minOccurs= "0" > <xs:element name= "responseHeader" type= "responseHeader" minOccurs= "1" /> <xs:choice minOccurs= "0" maxOccurs= "unbounded" > <xs:element name= "result" type= "result" /> response does not contain a tag called "responseHeader" or an attribute called "status". so there is no type called "responseHeader".
          Hide
          Chris A. Mattmann added a comment -

          Hi Noble:

          response does not contain a tag called "responseHeader" or an attribute called "status". so there is no type called "responseHeader".

          You're right – I think it's because the XSD is a bit old and the example response XML from before has changed slightly. I'll bring the XSD/DTD up to date.

          See: https://issues.apache.org/jira/secure/attachment/12334355/solr-complex.xml for an example of the old XML style.

          Cheers,
          Chris

          Show
          Chris A. Mattmann added a comment - Hi Noble: response does not contain a tag called "responseHeader" or an attribute called "status". so there is no type called "responseHeader". You're right – I think it's because the XSD is a bit old and the example response XML from before has changed slightly. I'll bring the XSD/DTD up to date. See: https://issues.apache.org/jira/secure/attachment/12334355/solr-complex.xml for an example of the old XML style. Cheers, Chris
          Hide
          Hoss Man added a comment -

          In the long term, maybe we could version the URIs too, based on the current SOLR version, but that's down the road.

          There are actually already multiple versions of the XML that can be produced by the current XmlResponseHandler based on the "version" param (see the source for details – they relate to how the header is produced and how single valued fields are output ... i think you already noticed this in a later comment) so we already really need to make sure the URIs are versioned (and the schema declarations generated by the response handler as well)

          as a start, can we make this issue just put the XSD/DTD into the src, and then copy it to a Forrest accessible link, and then a do site rebuild?

          Sure ... my main concern with doing something like that way back when was that it might fall by the wayside and get out of sync with the code, so i didn't want to commit until we were actually doing something with it so we could tell if we broke it (i'd rather have no XSD then a published, advertised, XSD that's completely wrong) ... but you're clearly on a roll here so i'm not really worried about losing momentum.

          Show
          Hoss Man added a comment - In the long term, maybe we could version the URIs too, based on the current SOLR version, but that's down the road. There are actually already multiple versions of the XML that can be produced by the current XmlResponseHandler based on the "version" param (see the source for details – they relate to how the header is produced and how single valued fields are output ... i think you already noticed this in a later comment) so we already really need to make sure the URIs are versioned (and the schema declarations generated by the response handler as well) as a start, can we make this issue just put the XSD/DTD into the src, and then copy it to a Forrest accessible link, and then a do site rebuild? Sure ... my main concern with doing something like that way back when was that it might fall by the wayside and get out of sync with the code, so i didn't want to commit until we were actually doing something with it so we could tell if we broke it (i'd rather have no XSD then a published, advertised, XSD that's completely wrong) ... but you're clearly on a roll here so i'm not really worried about losing momentum.
          Hide
          Bill Bell added a comment -

          Can we have a version of XSD for each released version of SOLR?

          solr14.xsd
          solr141.xsd
          solr31.xsd
          solrtrunk.xsd

          This would be very helpful, and we can keep it pretty open for now.

          Bill

          Show
          Bill Bell added a comment - Can we have a version of XSD for each released version of SOLR? solr14.xsd solr141.xsd solr31.xsd solrtrunk.xsd This would be very helpful, and we can keep it pretty open for now. Bill
          Hide
          David Barnes added a comment -

          Strongly second comment from Bill Bell. Working on a commercial project integrating Solr 3.1.
          Lack of an XSD is making integration with our business service back end a royal pain.
          We do have XSDs from all other 3rd parties we are integrating with. Using Solr commons connector is not an option for us.

          Show
          David Barnes added a comment - Strongly second comment from Bill Bell. Working on a commercial project integrating Solr 3.1. Lack of an XSD is making integration with our business service back end a royal pain. We do have XSDs from all other 3rd parties we are integrating with. Using Solr commons connector is not an option for us.

            People

            • Assignee:
              Unassigned
              Reporter:
              Mike Baranczak
            • Votes:
              8 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:

                Development