IVOA

VOStandard: an XML Encoding Schema for Standards Resource Metadata Version 0.2

IVOA Working Draft
25 April, 2007

This version:
http://www.ivoa.net/Documents/WD/ReR/VOStandard-XXXX.html
Latest version:
http://www.ivoa.net/Documents/latest/VOStandard.html
Previous versions
Authors:
Paul Harrison, Editor
Ray Plante
Guy Rixon
Dave Morris
and the IVOA Registry Working Group.

Abstract

This document describes an XML encoding standard for metadata about IVOA standards themselves, referred to as VOStandard. We describe the general model for the schema and explain how it may be included in other schema as a methodology of avoiding XML enumerations. This schema is primarily intended to support interoperable registries used for discovering resources.

Status of this document

This is an IVOA Working Draft for review by IVOA members and other interested parties. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use IVOA Working Drafts as reference materials or to cite them as other than "work in progress."

Parts that the editor considers should be removed from the document are marked in red with a strike through line. , and sections that need more work are indicated in green

Comments on this document are due 15 December 2006 for consideration in the next version of this document. They should be sent to registry@ivoa.net, a mailing list with a public archive or on the VOStandard twiki discussion page. General discussion of related technology is also welcome on the Rwp03 wiki site.

A list of current IVOA Recommendations and other technical documents can be found at http://www.ivoa.net/Documents/.

Acknowledgements

This document has been developed with support from the National Science Foundation's Information Technology Research Program under Cooperative Agreement AST0122449 with The Johns Hopkins University, from the UK Particle Physics and Astronomy Research Council (PPARC), and from the Eurpean Commission's Sixth Framework Program.

Conformance-related definitions

The words "MUST", "SHALL", "SHOULD", "MAY", "RECOMMENDED", and "OPTIONAL" (in upper or lower case) used in this document are to be interpreted as described in IETF standard, RFC 2119 [RFC 2119].

The Virtual Observatory (VO) is general term for a collection of federated resources that can be used to conduct astronomical research, education, and outreach. The International Virtual Observatory Alliance (IVOA) is a global collaboration of separately funded projects to develop standards and infrastructure that enable VO applications.

XML document validation is a software process that checks that an XML document is not only well-formed XML but also conforms to the syntax rules defined by the applicable schema. Typically, when the schema is defined by one or more XML Schema [Schema] documents (see next section), validation refers to checking for conformance to the syntax described in those Schema documents. This document describes additional syntax constraints that cannot be enforced solely by the rules of XML Schema; thus, in this document, use of the term validation includes the extra checks that goes beyond common Schema-aware parsers which ensure conformance with this document.

Syntax Notation Using XML Schema

The eXtensible Markup Language, or XML, is document syntax for marking textual information with named tags and is defined by the World Wide Web Consortium (W3C) Recommendation, XML 1.0 [XML]. The set of XML tag names and the syntax rules for their use is referred to as the document schema. One way to formally define a schema for XML documents is using the W3C standard known as XML Schema [Schema].

This document defines the VOStandard schema using XML Schema. The full Schema document is listed in Appendix A. Parts of the schema appear within the main sections of this document; however, documentation nodes have been left out for the sake of brevity.

Reference to specific elements and types defined in the VOStandard schema include the namespaces prefix, vstd, as in vstd: (a type defined in the VOStandard schema). Use of the specific va prefix in compliant instance documents is not required (the namespace could be assigned to any prefix); its use in this document is simply to indicate that it is an entity defined in the VOStandard schema.

Contents

1 Introduction

The goal of the IVOA is to publish a number of standards for services which can interoperate to create a Virtual Observatory. Central to the coordination of these services is the concept of a registry ([RegInt]) where resources can be described and thus discovered by elements in the grid. The standard Resource Metadata for the Virtual Observatory [Hanisch et al. 2004] (hereafter referred to as RM) defines metadata terms for describing resources. A specific XML encoding of these resources is described in the IVOA standard VOResource: an XML Encoding Schema for Resource Metadata [Plante et al. 2006] (hereafter refered to as the VR). In this document there are several elements that have a standardID attribute that should have a value of a resource identifier as defined in [ID] . There is no formal validation requirement in the schema that the identifier actually point to a resource entry in the registry. This schema allows such standards to be registered so that there can be an unambigous, machine-readable entry made in a registry for each approved IVOA standard. This would allow automatic resource validation applications to be written that can check validity constraints beyond that of simple XML validity. In addition the schema provides a standard way to economically register sets of such identifiers that could be then used for resource identifier enumerations in other schema.

It is envisaged that instances conforming to this schema will normally only be published in the central "registry of registries", but they are not restricted only to that registry.

This document specifically describes an extension of the metadata concepts and an XML encoding called VOStandard. The VOStandard schema provides XML encoding that extends the VR so that can be used to describe applications (see section below for discussion of what constitues an application).

Details of the VOStandard Schema

In accordance with the guidelines laid down by [VR], there has been no attempt to create enumerated lists for cases where there list could not be closed (e.g. the set of operating system names will grow as new operating systems are developed). This means that the values of certain elements in a document instance will not be checked by even a validating XML parser, and validation that the element contents are allowed will have to be done by a separate process. This section will list the allowed values for those enumerations where appropriate and instance documents MUST use these exact strings to represent the same concept.

Use of the VOStandard Schema

It should be noted that in many cases there is no need to introduce a dependency on this schema in other registry schemas e.g. the VOResouce schema does not include the VOStandard schema - it simply defines a type vr:ResourceIdentifier that limits a string to have the correct resource identifider syntax. XML entities registered using the VOResouce schema SHOULD refer to entities registered with the VOStandard schema when creating a standardID attribute, although there is no compulsion in the XML schema language to do so. The major IVOA standards will already have an appripriate standard describing resource registered, however it should always be possible for an 'experimental' standard to be registered.

Details of the elements for defining Standards

TBC

Defining enumerations of Identifiers

The second major structure in the VOStandard schema is the ResourceEnumList type, which is designed to allow sets or enumerations of resource identifiers to be registered. The typical use of this facility is to avoid having to create formal xml string enumerations in schema definitions. Using enumerations in schema for lists that cannot be closed at the time of initial release is undesirable because it implies that new versions of schema would need to be released when the enumeration changes, with consequent disruption to deployed services. However, not having a machine readable definition of the enumerations is also undesirable as it means that any validation application would also have to updated as the list expanded - registering the enumerations provides a good mixture of flexibility and rigour.

The structure that is used to achieve this aim is simply defined as a list of names with an accompanying description. The intention is that the name attribute in the BaseKey is used as the "fragment" part of the resource identifier URI i.e. the part after the # in the URI string. e.g.

ivo://authority/resource#name

This form of defining enumerations has several advantages over defining each member of the enumeration as a separate resource

An example of BaseKey usage

A good example of where an enumeration is not closed is that of the names of programming languages.

An example of defining a list of programming languages
  <p:Resource xsi:type="vstd:ResourceEnumList" created="2001-12-31T12:00:00"
updated="2001-12-31T12:00:00" status="active">
<title>application languages</title>
<identifier>ivo://net.ivoa.application/languages</identifier>
<curation>
<publisher>IVOA</publisher>
<creator>
<name>IVOA</name>
<logo>http://www.ivoa.net/icons/ivoa_logo_small.jpg</logo>
</creator>
<date role="representative">2006-07-17</date>
<version>1.0</version>
<contact>
<name>IVOA Grid Registry WG</name>
<email>registry@ivoa.net</email>
</contact>
</curation>
<content>
<subject>standard language identifiers</subject>
<description>These language identifiers are to be used in the value of the va:ProgrammingLanguage type</description>
<referenceURL>http://www.ivoa.net/twiki/bin/view/IVOA/IvoaResReg</referenceURL>
</content>
<key name="C">
<description>The C programming language</description>
</key>
<key name="CPP">
<description>The C++ programming language</description>
</key>
<key name="CSharp">
<description>The C# programming language</description>
</key>
<key name="FORTRAN">
<description>The FORTRAN programming language</description>
</key>
<key name="Java">
<description>The Java programming language</description>
</key>
<key name="Perl">
<description>The Perl programming language</description>
</key>
<key name="Python">
<description>The Python programming language</description>
</key>
</p:Resource>

 

Note

When these enumerations are presented to a user in a GUI it is expected that the only the "fragment" part that distinguishes the various members of the enumeration will be used as a choice value, as the full IVO ID is not usually particularly "user-friendly".

Extending the BaseKey

The structure can be extened to provide additional metadata that is associated with the resource identifier. The diagram below shows how this structure is extended in the VOSpaceResource schema to add information about particular protocols.

ResourceEnumList use

 

Appendix A: The complete VOStandard Schema

Note that this schema can be found on-line at http://www.ivoa.net/xml/VOStandard/v0.2 (i.e. the target namespace can also be used as a URL for the schema not yet uploaded for this draft) This location should represent the definitive source, the schema is only copied below for completeness of this document.

Appendix B: Standards instance

This is an example of the ivoa standards that can be defined with the VOStandard Schema. This example should not be taken as the definitive definition for any standards mentioned - an IVOA registry should always be consulted, where the standards will be registered under the authority identifier net.ivoa.standards

Appendix C: Change History

This is the first version that has been made public - it is derived from wiki content.

References

[RFC 2119]
Bradner, S. 1997. Key words for use in RFCs to Indicate Requirement Levels, IETF RFC 2119, http://www.ietf.org/rfc/rfc2119.txt
[RM]
Hanisch, Robert (ed.) 2004. Resource Metadata for the Virtual Observatory, Version 1.01, IVOA Recommendation, http://www.ivoa.net/Documents/REC/ResMetadata/RM-20040426.htm
[VR]
Plante, Ray (ed.) 2006. VOResource: an XML Encoding Schema for Resource Metadata, IVOA Working Draft, http://www.ivoa.net/Documents/latest/VOResource.html
[CEA]
Harrison, Paul. 2006. VOCEA: Schema , IVOA Working Draft, http://www.ivoa.net/Documents/latest/VOCEA.html
 
[xml]
Bray, Tim, Paoli, Jean, Sperberg-McQueen, C. M., Maler, Eve, Yergeau, Francois (editors) 2004, Extensible Markup Language (XML) 1.0 (Third Edition), W3C Recommendation 04 February 2004, http://www.w3.org/TR/REC-xml
[schema]
Fallside, David C., Walmsley, Priscilla (editors) 2004, XML Schema Part 0: Primer Second Edition, W3C Recommendation 28 October 2004, http://www.w3.org/TR/xmlschema-0/
[ISO8601]
Wolf, Misha and Wicksteed, Charles 1997, Date and Time Format, http://www.w3.org/TR/NOTE-datetime.
[ID]
Plante, R., Linde, T., Williams, R., Noddle, K. 2005, IVOA Identifiers v1.1, http://www.ivoa.net/Documents/REC/Identifiers/Identifiers-200505XX.html.
 

Last modified: 25-Apr-2007 15:55