16 May 2006IVOA Interoperability – Registries WG1 VOResource Schema v1.0 Release 6 Ray Plante NCSA T HE I NTERNATIONAL V IRTUAL O BSERVATORY A LLIANCE 1.General Changes since Kyoto 2.Revised Service Model

16 May 2006IVOA Interoperability – Registries WG2 Roadmap for VOResource Schemas Aiming to upgrade registries to RI v1.0 this summer –Dependencies: RI v1.0 => VOResource v1.0, ADQL v? => RM v1.1, Identifiers v1.0 VOResource v1.0: Core Metadata & Model –Move to PR status ASAP –Components: Core metadata from RM v1.1 New Service model VORegistry v1.0: for supporting RI –To be incorporated into RI v1.0 (ASAP) VODataService v1.0, SIA v1.0, ConeSearch v1.0, SkyNode v1.0 –Over the next six months –Coordinate with next revisions of DAL services –Focus on issues of fine vs. coarse grain registries VOStandard v1.0 (new) –~ 1 year

16 May 2006IVOA Interoperability – Registries WG3 VOResource v1.0 Specification Overview –Builds on Resource Metadata v1.0 Adopts names and definitions –Basic Data Model Overall Model (mapping RM to Schema) –Including new Service Model Conventions for XML definitions How to extend the schema –Detailed XML definitions Complete, explicit semantic definition of EVERY element name Reference manual approach

16 May 2006IVOA Interoperability – Registries WG4 VOResource: Miscellaneous Changes 1.Require full timestamp on created, updated Date handling n previous release: All dates must be UTC:, created, updated Allowed either xs:date or xs:dateTime via a xs:union or :09:15:00Z code generator note: wsdl2java returns Calendar type Required “Z” suffix to denote UTC Disallow future times Proposed change: created, updated: xs:dateTime Drop forcing “Z” suffix on timestamps Just assume UTC

16 May 2006IVOA Interoperability – Registries WG5 VOResource: Miscellaneous Changes 2.Relationships: –Was: –Now: –Alt: –Why: allows new relationship names to be defined in an extension schema without requiring an update to the VOResource core schema Use xsi:type to select the desired set of relationship types to draw from service-for NCSA Astronomy Digital Image Library NCSA Astronomy Digital Image Library service-for NCSA Astronomy Digital Image Library service-for

16 May 2006IVOA Interoperability – Registries WG6 VOResource: Miscellaneous Changes 3.Move WebService Interface sub-type to core schema Definition: A Web Service that is describable by a WSDL document –Allows description of a generic WS without an extension schema –accessURL is the service endpoint

16 May 2006IVOA Interoperability – Registries WG7 VOResource: Miscellaneous Changes 4.elementFormDefault=“unqualified” –“qualified” means “locally-defined” elements: must indicate element’s namespace –xmlns=“ –Or via namespace prefix: Gets messy when combining terms from different schemas XPaths must include prefixes vr:capability/sia:maxRecords –“unqualified”: no xmlns, prefixes Types that appear in xsi:type still need prefix Authors don’t have to worry about which elements are part of which schema –-- less error prone! Simpler XPaths Capability/maxRecords

16 May 2006IVOA Interoperability – Registries WG8 VODataServices: Miscellaneous Changes 1.Change Resource class name: SkyService -> DataService, ObsDataService, or ?? –Metadata added beyond core: Facility, Instrument, Coverage 2.Change Resource class name: TabularSkyService -> CatalogService –Metadata added beyond SkyService: Table

16 May 2006IVOA Interoperability – Registries WG9 VODataServices: Miscellaneous Changes 3.STC integration –Contents: stc:STCResourceProfile, footprint, waveband –Issues: STC uses elementFormDefault=“qualified” –Must use namespace prefix on STC element Regsitry can not index it in same way as other registry data –Complex model with many alternate markup –Searching will require special tranformation Will require help for authors on creating STC descripitons.

16 May 2006IVOA Interoperability – Registries WG10 New Service Model Goals: 1.Indicate standard version; Multiple version support 2.Support multiple endpoints covering different parts of a single, logical service 3.Allow descriptions of additional, non-standard interfaces 4.Clarify the association between service capability metadata and interface that supports the capability

16 May 2006IVOA Interoperability – Registries WG11 New Service Model

16 May 2006IVOA Interoperability – Registries WG12 New Service Model Bring together various related service capabilities together into one logical Resource record: “Service with capabilities” Structure: –Service has one or more elements Capability type specialized for standard services –Interface has one or more elements Indicates which version is supported List alternate interfaces Finding ConeSearch services: like “%:ConeSearch” –v1.0: like “%:ConeSearch” Add as child of –Allows different capabilities to be evaluated independently –This validationLevel focuses capability metadata and compliance with service standard (e.g. ConeSearch) –Top level validationLevel remains, focuses on core metadata description Extra metadata validation required –Limitations in XML Schema make it difficult enforce required combinations of Resource, Capability, and Interface types Would result in less uniform descriptions of services –Expect to incorporate this into emerging validation framework

16 May 2006IVOA Interoperability – Registries WG13 New Service Model <capability xsi:type="sn:SkyNode" standardID="ivo://ivoa.net/std/SkyNode">

16 May 2006IVOA Interoperability – Registries WG14 New Service Model Alternate way to identify support for standard: standardID="…" –Useful when standard does not require specialized capability metadata. Lower cost to registries, applications for adding support –Use of IVOA Identifier implies registration of standard in a registry Propose to register IVOA standards in the IVOA “Registry of Registries” Local standards could be registered anywhere VOStandard: schema for describing standards –standardID can lead users to specification documents standardID -> service standard record -> –Can include other information useful to workflow & GUI-builders Interface: all content data is optional except –Previously, an SIA interface description included redundant metadata ParamHTTP interface: output MIME type, input parameters (including required ones) Good for supporting workflow & automatic GUI builders In practice, SIA-aware applications ignore all info but accessURL –Now: service standard entry can contain description of default interface an SIA –Implementation record may list support for optional or non-standard parameters