[Volute] r3561 - trunk/projects/registry/RegistryInterface

Volute commit messages volutecommits at g-vo.org
Wed Oct 26 18:05:32 CEST 2016


Author: msdemlei
Date: Thu Sep 22 12:52:22 2016
New Revision: 3561

Log:
RI 1.1: minor typography-type fixes.

Modified:
   trunk/projects/registry/RegistryInterface/RegistryInterface.tex
   trunk/projects/registry/RegistryInterface/VORegistry-1.0.xsd

Modified: trunk/projects/registry/RegistryInterface/RegistryInterface.tex
==============================================================================
--- trunk/projects/registry/RegistryInterface/RegistryInterface.tex	Thu Sep 22 11:26:23 2016	(r3560)
+++ trunk/projects/registry/RegistryInterface/RegistryInterface.tex	Thu Sep 22 12:52:22 2016	(r3561)
@@ -738,7 +738,7 @@
 
 The Registry of Registries includes the VOResource records directly representing each currently active registry of IVOA resources, be they fully searchable or publishing registries providing only an OAI-PMH harvesting interface. These resources are of type \xmlel{vg:Registry} as defined in section \ref{sect:resext}. 
 
-Once a registry provider has deployed a new publishing registry, they must enroll it the RofR for full-search registries (and therefore registry search clients) to be able to find their records. The RofR provides a dedicated web-based interface for this purpose accessible from http://\nolinkurl{http://rofr.ivoa.net}.  The RofR includes a validator package, which thoroughly checks the new registry, including schema validation for the OAI interface itself and all listed resources. The registration process will only accept registries that validate successfully.  Local updates within a publishing registry post-inclusion in the RofR are not necessarily automatically validated by the RofR software later: the validator tool can, and indeed should, be used independently of the first admission process by the registry providers to periodically make sure their registries are still compliant with the relevant IVOA standards. 
+Once a registry provider has deployed a new publishing registry, they must enroll it the RofR for searchable registries (and therefore registry search clients) to be able to find their records. The RofR provides a dedicated web-based interface for this purpose accessible from http://\nolinkurl{http://rofr.ivoa.net}.  The RofR includes a validator package, which thoroughly checks the new registry, including schema validation for the OAI interface itself and all listed resources. The registration process will only accept registries that validate successfully.  Local updates within a publishing registry post-inclusion in the RofR are not necessarily automatically validated by the RofR software later: the validator tool can, and indeed should, be used independently of the first admission process by the registry providers to periodically make sure their registries are still compliant with the relevant IVOA standards. 
 
 The Registry of Registries also contains the canonical VOResource descriptions of the most recent versions of VOResource standards and extensions themselves, which are of type \xmlel{vstd:Standard}.
 
@@ -765,7 +765,7 @@
 general registry maintenance with client interfaces to the registry,
 which were found to be in much more need of experimentation.  For a
 discussion of the history of client interfaces in the VO, see
-\citep{paper:regclient}.
+\citet{paper:regclient}.
 
 One second-generation standard search interface to the VO Registry that
 has progressed to become an IVOA recommendation is RegTAP
@@ -773,11 +773,11 @@
 major parts of VOResource and the VO's TAP protocol \citep{std:TAP}.
 RegTAP services have been made available from several registry providers listed in the Registry of Registries.
 
-An earlier search capability, RISearch, is not removed
+An earlier search capability, \xmlel{vg:RISearch}, is not removed
 from the schema in order to allow operators to register RI1 registries without having to support different versions of the VORegistry schema.
 Also, the type may be useful when other registry search interfaces want to define capability types of their own.
 
-Registry TAP Service capabilities and other additional search capabilities other than the deprecated but allowed RISearch are to be included in the registry self-identification record as an auxiliary capability as described in the IVOA note "Discovering Data Collections Within Services" \citep{note:DataCollect}, with the main capability being the OAI-PMH harvester service endpoint.
+RegTAP service capabilities and other additional search capabilities other than the deprecated but allowed RISearch are to be included in the registry self-identification record as an auxiliary capability as described in the IVOA note "Discovering Data Collections Within Services" \citep{note:DataCollect}, with the main capability being the OAI-PMH harvester service endpoint.
 
 The concept of a searchable registry versus a publishing one as recognized by the Registry of Registries therefore now encompasses any registry implementing an IVOA standard programmatic interface beyond the interface for OAI harvesting. That is, any Registry resource with an additional capability or auxiliary capability referencing an IVOA standard and a ParamHTTP interface element to that capability.
 

Modified: trunk/projects/registry/RegistryInterface/VORegistry-1.0.xsd
==============================================================================
--- trunk/projects/registry/RegistryInterface/VORegistry-1.0.xsd	Thu Sep 22 11:26:23 2016	(r3560)
+++ trunk/projects/registry/RegistryInterface/VORegistry-1.0.xsd	Thu Sep 22 12:52:22 2016	(r3561)
@@ -6,7 +6,7 @@
            xmlns:vs="http://www.ivoa.net/xml/VODataService/v1.1" 
            xmlns:vm="http://www.ivoa.net/xml/VOMetadata/v0.1"
            elementFormDefault="unqualified" attributeFormDefault="unqualified"
-           version="1.0wd">
+           version="1.0.1">
 
    <xs:annotation>
       <xs:appinfo>


More information about the Volutecommits mailing list