[
https://issues.apache.org/jira/browse/SOLR-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12791042#action_12791042
]
Chris A. Mattmann commented on SOLR-17:
---------------------------------------
Hi Uri:
Thanks. Comments below:
{quote}
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).
{quote}
+1.
{quote}
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.
{quote}
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
> XSD for solr requests/responses
> -------------------------------
>
> Key: SOLR-17
> URL: https://issues.apache.org/jira/browse/SOLR-17
> Project: Solr
> Issue Type: Improvement
> Reporter: Mike Baranczak
> Priority: Minor
> Attachments: solr-complex.xml, solr-rev2.xsd, solr.xsd,
> UselessRequestHandler.java
>
>
> 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?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
