RegDMServices < IVOA

<small>Jumps:  IvoaResReg :: [[http://www.ivoa.net/forum/registry/][reg-dm mail archive]] :: ResourceMetadata
<br> Meetings: InterOpMay2004ResReg :: InterOpMay2005ResReg :: InterOpOct2005ResReg :: InterOpMay2006ResReg </small>

---+!! Registry Data Model:  Services

This page summarizes the state of the model for describing services as discussed by the Registry-DM tiger team.  

__Contents__
%TOC%
---

---++ Goals

The model for describing services was revisited to address several needs.  In particular, a revised model needs to allow:

   1  _multiple version support_ -- it is necessary for the standard services to describe not only what version of a standard they are compliant with but to allow support for multiple versions simultaneously.  It would be conventient if a support for multiple versions could be described within a single resource record.  
   1  _multiple endpoints covering different parts of a logical interface_ -- Supported use cases must be allowed:
      * the Registry service interface has 2 components: searching and harvesting; each can have their own endpoint and feature a different class of interface (soap web service vs. the standard OAI interface).
      * a service such as a <nop>SkyNode can not only support standard <nop>SkyNode interface, it might also support other interfaces to functionality that can be used in conjunction with the <nop>SkyNode interface but which are described by a different standards.  Possible examples include VOStore or the standard support services.  
   1  _including in the description of a service additional, non-standard interfaces_ -- providing via a different endpoint URL additional interfaces that are not part of the standard but which access essentially the same underlying data or information.  
   1  _clarifying the association between service capability metadata and interface that supports the capability_ -- previously, when a service description included multiple interfaces, it was not clear which of those interfaces was associaed with the specific service capability metadata.  The association between capability and interface needs to be made clearer.  

---++ Summary of Proposed Changes

---+++ Proposal #1

<ol>
   <li> &lt;interface&gt; is now a child of &lt;capability&gt;. 

This solidifies the connection between a set of capability metadata and the interfaces that provide that capability.  

   <ul>
      <li> A &lt;capability&gt; element may include multiple &lt;interface&gt; children.  This is interpreted to mean that each interface provides access to the same (logical) capability and has essentially the same behavior.  As an example, a &lt;capability&gt; may include both a <nop>WebService interface and an interactive <nop>WebBrowser interface; the latter simply provides a GUI wrapping of the soap interface.  </li>

      <li> The &lt;interface&gt; (or interfaces) that are mandated by standard service described by the &lt;capability&gt; will have an attribute called "std" which will be set to "true".  </li>

      <li> The different sub-types of interfaces (<nop>WebService, <nop>WebBrowser, <nop>ParamHTTP, etc.) are still differentiated via an xsi:type attribute to the &lt;interface&gt; element.
    </ul></li>

   <li> A Service resource class no longer contains &lt;interface&gt; elements as direct children; instead it contains one or more &lt;capabiltiy&gt; elements.  

   <li> We no longer describe standard services (like SIA) as sub-classes of the Service resource class; instead, we describe a generic Service resource and show its support for a standard protocol via the presence of the associated standard capability description.  Thus, a generic service can support multiple standard protocols (via multiple &lt;capabiltiy&gt; elements) simultaneously.  

Another way to look at this is that we no longer describe an SIA service; rather, we describe a service with an SIA capability.  That same service can also have a <nop>ConeSearch capability, a VOStore capability, etc.

   <ul>
      <li> Standard protocols that need to define specialized capability metadata do so in a subclass of the Capability type.  The xsi:type mechanism is used to include the specialized capability element into the service description.</li>

      <li> The Service subclasses, <nop>SkyService and <nop>TabularSkyService, are retained to include descriptions of coverage and the tables engaged by the service.  An SIA Capability should be a part of a <nop>TabularSkyService.</li>

      <li> Services (or more precisely, service capabilities) that have no specialized capability metadata defined--in particular, non-standard services--use the base &lt;capabiltiy&gt; element with no xsi:type attribute to hold the description of the interface.  The optional &lt;description&gt; child of &lt;capabiltiy&gt; may be used to provide a human-readable description of what the capability provides.  </li>
   </ul></li>

   <li> The schemas will not attempt to enforce that a particular type of interface mandated by a standard be included in the standard capability.

For example, the <nop>SimpleImageAccess capability type does not require that the required <nop>ParamHTTP interface be included inside the capability description.  

This enables a uniform way of identifying interface types:  via the value of the &lt;interface&gt; element's xsi:type.  Enforcing the inclusion of the required interface types will be done outside the context of a Schema-validating parser using a specialized VO registry validator.  

Similarly, the schemas will not attempt to enforce, for example, that an SIA capability appear only within the context of a <nop>TabularSkyService; this will also be checked by a specialized VO registry validator.  </li>

   <li> The base Capability type will include an optional attribute called "standardID" which holds an unambiguous identifier (URI) for the standard that the service adheres to.  For standard services that have defined a specialized subclass of Capability, this attribute will be fixed to the identifier for that standard.  

A leading idea is that this URI would be an IVOA identifier; this would require that a resource describing a standard would be registered.  This provides three advantages:
      <ul>
         <li> By not defining a specialized Capability sub-type, one lowers the cost for supporting the capability both within a registry and in registry clients; the standardID attribute then becomes the way to identify the standard capability. </li>
         <li> We leverage the existing registry framework for ensuring standard IDs are unique and unambiguous.  </li>
         <li> The resource record that describes the standard provides a way for users to find the definition of the standard (via the referenceURL element).  This is important for non-IVOA standards in which the location of the relevent standard documents is not widely known.  </li>
      </ul>
This idea, however, is controversial (see issues below).  
   </li>

   <li> The &lt;interface&gt; element will include an optional "version" attribute which identifies which version of the standard that interface supports.  

   <ul>
      <li> the meaning of the version attribute is undefined when the parent &lt;capabiltiy&gt; element's standardID is not given. </li>

      <li> Assuming standardID holds an IVOA identifier, the description of the standard pointed to by that identifier would include a list of recognized versions.  The value of the version attribute must match one of the recognized versions.  </li>

      <li> A service that supports multiple versions of, say, SIA, would include multiple &lt;interface&gt;s of the proper type (and with std="true") inside the <nop>SimpleImageAccess &lt;capability&gt; element.  </li>
   </ul></li>
</ol>

---++++ Schemas and Example Instances

All of the schemas and examples can be downloaded together:  [[%ATTACHURL%/VORes-v1.0.tar.gz][VORes-v1.0.tar.gz]].

Individual examples:
| Schema | Sample intance |
| [[%ATTACHURL%/VOResource-v1.0.xsd][VOResource-v1.0.xsd]] |   [[%ATTACHURL%/organisation.xml][organisation.xml]] <br>  [[%ATTACHURL%/webform.xml][webform.xml]] <br>  [[%ATTACHURL%/webservice.xml][webservice.xml]] |
| [[%ATTACHURL%/VODataService-v1.0.xsd][VODataService-v1.0.xsd]] |  [[%ATTACHURL%/collection.xml][collection.xml]] |
| [[%ATTACHURL%/ConeSearch-v1.0.xsd][ConeSearch-v1.0.xsd]] |  [[%ATTACHURL%/conesearch.xml][conesearch.xml]] |
| [[%ATTACHURL%/SIA-v1.0.xsd][SIA-v1.0.xsd]] |  [[%ATTACHURL%/sia.xml][sia.xml]] <br> [[%ATTACHURL%/sia2ver.xml][sia2ver.xml]]|
| [[%ATTACHURL%/VORegistry-v1.0.xsd][VORegistry-v1.0.xsd]] |  [[%ATTACHURL%/registry.xml][registry.xml]] |  
|[[%ATTACHURL%/VOStandard-v1.0.xsd][VOStandard-v1.0.xsd]] |  [[%ATTACHURL%/siastd.xml][siastd.xml]] |

---++++ Issues and Concerns

   * "Service with capabilities" model does not integrate well with the validation level, which is provided on a per resource basis. 
   * forcing value of standardID for IVOA standard services required setting elementDefaultForm="unqualified"   
<em>
   * interfaces inside of capability
   * registering standards
</em>
   *  

-- IVOA.RayPlante - 25 Apr 2006

---+++ Proposal #2
__Aurelien Stebe__

<ol>
  <li>
&lt;Capability&gt; is now an abstract element and an optional child of &lt;Service&gt;.<br />
&lt;Service&gt; now has two multiple optional child elements : &lt;Interface&gt; and &lt;Capability&gt;. Both elements need to be extended and declared in the resource document using "xsi:type".
    <ul>
      <li>
&lt;Interface&gt; is used to fully describe an endpoint, independently of any standard protocol specification, with it's parameters and output description, just as it is in the current version (0.10) of the schemas.
      </li>
      <li>
&lt;Capability&gt; is used to fully describe the support from a service for a specific protocol specification, just as it is in the current version (0.10) of the schemas.
      </li>
    </ul>
  </li>
  <li>
The &lt;Capability&gt; extensions will be expected to include an element giving the service endpoint(s) and the version(s) of the specification supported. A "ServiceEndpointURL" element type is proposed for this. It is advised to use it in &lt;Capability&gt; extensions, but a different element type may be used.

All service specifications will be expected to provide its specific &lt;Capability&gt; extension to allow for that service entries to be specified in a Registry.
  </li>
  <li>
Standard services are now identified by the presence of its corresponding &lt;Capability&gt; extension. Just as point 3 of Proposed Solution #1, except that all service must declare a specific extension of &lt;Capability&gt; using "xsi:type".
  </li>

This solution has the advantage of offering the possibility for full Interface description and multiple standard service Capability presentation, with a minimum of modifications to the current schemas. Here are for example the modified versions of VOResource, SIA and Registry schemas : [[%ATTACHURL%/VOResource-v0.10-prop2.xsd][VOResource.xsd]], [[%ATTACHURL%/SIA-v0.7-prop2.xsd][SIA.xsd]], [[%ATTACHURL%/VORegistry-v0.3-prop2.xsd][VORegistry.xsd]]

Here is what an instance of SIA or Registry service entry would look like :
<pre>
&lt;resource xsi:type="Service"&gt;
  .............
  &lt;interface xsi:type="ParamHTTP"&gt;
    &lt;accessURL use="base"&gt; http://...../..../siap.jsp &lt;/accessURL&gt;
    ..............
  &lt;/interface&gt;
  &lt;capability xsi:type="SIACapability"&gt;
    &lt;siaEndpointURL version="1.0"&gt; http://...../..../siap0.jsp &lt;/siaEndpointURL&gt;
    &lt;siaEndpointURL version="1.1"&gt; http://...../..../siap1.jsp &lt;/siaEndpointURL&gt;
    &lt;maxQueryRegionSize&gt; ..... &lt;/maxQueryRegionSize&gt;
    &lt;maxImageExtent&gt; ..... &lt;/maxImageExtent&gt;
    ..............
  &lt;/capability&gt;
&lt;/resource&gt;
</pre>
<pre>
&lt;resource xsi:type="Service"&gt;
  .............
  &lt;interface xsi:type="WebService"&gt;
    &lt;accessURL use="full"&gt; http://...../..../Search &lt;/accessURL&gt;
  &lt;/interface&gt;
  &lt;interface xsi:type="WebService"&gt;
    &lt;accessURL use="full"&gt; http://...../..../Harvest &lt;/accessURL&gt;
  &lt;/interface&gt;
  &lt;interface xsi:type="ParamHTTP"&gt;
    &lt;accessURL use="base"&gt; http://...../..../oai.jsp &lt;/accessURL&gt;
    ..............
  &lt;/interface&gt;
  &lt;capability xsi:type="RegistryCapability"&gt;
    &lt;searchEndpointURL version="0.9"&gt; http://...../..../Search &lt;/searchEndpointURL&gt;
    &lt;searchEndpointURL version="0.10"&gt; http://...../..../Search &lt;/searchEndpointURL&gt;
    &lt;harvestEndpointURL version="0.10"&gt; http://...../..../Harvest &lt;/harvestEndpointURL&gt;
    &lt;managedAuthority&gt; ..... &lt;/managedAuthority&gt;
    &lt;managedAuthority&gt; ..... &lt;/managedAuthority&gt;
  &lt;/capability&gt;
&lt;/resource&gt;
</pre>
</ol>
---++++ Issues and Concerns

---++ Model Diagram




<br/>
<!--
      * Set ALLOWTOPICRENAME = %MAINWEB%.TWikiAdminGroup
-->

   * : for proposal #1
Attachments
Topic attachments
I	Attachment	History	Action	Size	Date	Who	Comment
xsd	SIA-v0.7-prop2.xsd	r1	manage	12.8 K	2006-03-24 - 16:20	AurelienStebe	SIA schema for Proposition #2
xsd	VORegistry-v0.3-prop2.xsd	r1	manage	2.5 K	2006-03-24 - 16:20	AurelienStebe	VORegistry schema for Proposition #2
gz	VORes-v1.0.tar.gz	r1	manage	21.1 K	2006-04-25 - 08:13	RayPlante	Sample XSDs and instances for proposal #1
xsd	VOResource-v0.10-prop2.xsd	r1	manage	41.0 K	2006-03-24 - 16:20	AurelienStebe	VOResource schema for Proposition #2
This topic: IVOA > WebHome > IvoaResReg > RegistryModel > RegDMServices
Topic revision: r7 - 2006-04-27 - RayPlante