StandardsRegExt: links to schemas
m.b.taylor at bristol.ac.uk
Mon Feb 20 02:36:25 PST 2012
If the main use case is, as you say, human discovery of the schemas,
it doesn't seem to add all that much benefit, since for a human making
use of such a registry record, the cost of the additional step of
indirecting via the human-readable standard document itself is likely
to be low compared with whatever use is being made of it
(e.g. trying to understand what it means and how to use it).
Having said that, the content of this sounds reasonable and harmless
enough, though I haven't thought about it in great detail.
However, introducing new functionality at the TCG review stage
is by my reading contrary to the document review process as currently
formalized in the DocStd document, and it means there will have been
no IVOA-wide review of this part of the standard. It does seem to
be the case however that DocStd is not universally followed to the
letter, so maybe that doesn't matter enough to block what looks like
a fairly minor change. I think the TCG (CC'd) needs to be consulted about
whether it's OK to make this change at this stage, but if there is
general agreement I won't argue against it.
On Fri, 17 Feb 2012, Ray Plante wrote:
> Hi again,
> Following up more on TCG review comments, we had a very good
> suggestion from Andreas Wicenec recommending that we not only make the
> human-readable standards document discoverable via this record but
> also the schema document. Providing a link to an example instance is
> also suggested. I want to propose a means for doing this and your
> feedback is requested. In particular, if anyone thinks it is too late
> in the process to introduce additional elements into the schema.
> Here's an example of what I propose
> <schema namespace="http://www.ivoa.net/xml/SIA/v1.0">
> <description>VOResource extension schema for registering SIA
> Here are definition details:
> o this would be part of a vstd:Standard resource type (and
> thus inherited by vstd:ServiceStandard)
> o the <schema> element would be optional and could appear multiple
> o the <schema> element could appear multiple times
> o the namespace attribute and <locationURL> would be required
> o the <description> element is optional
> o the <example> element would be optional and could appear
> multiple times
> Note that some of our standards define multiple schemas (e.g.
> SimpleDALRegExt and RegistryInterface), thus the need for multiple
> occurances. When we have multiple occurances, we need a way to
> distinguish between them: the namespace attribute serves as the
> label, and the <description> element differentiates them for the human
> viewer. Note that for IVOA schemas, the namespace and location are
> identical; however, this would not necessarily be true for non-IVOA
> schemas nor for working draft versions.
> Note also that the schemas are not necessarily independent of each
> other; consequently, an example might well require or benefit from the
> use of multiple schemas. The publisher can choose the most
> appropriate <schema> element to put the example into (or could even
> repeat the URL across multiple <schema> elements).
> I made no attempt to identify what type of schema it is. Doing so
> implies that we are supporting automated interpretation of the
> underlying documents. I feel this would be too complicated to support
> without further work (and a clear use case). The main use case we are
> targeting is human discovery of the schemas.
If the main use case is human discovery of the schemas, there doesn't
seem to be that much gain
> I've attached the bit of XML that would be added to the
> StandardsRegExt schema to support this if you want to see the details.
> I've also appended a full example, StandardsRegExt.xml.
Mark Taylor Astronomical Programmer Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/
More information about the registry