The primary goal of this set of sessions will be to sign off on V1.0 of Registry schemas and Registry interface. We will also discuss whether to make these two and the current Registry Metadata document into a single standard.
Sessions and their agenda will be posted here nearer the meeting date.
The issue of the usability of registry interface applications was raised: how easy it was for users (primarily data centre persons) to enter and maintain resource information. It was AGREED that the Registry sessions for the September Interop meeting in Moscow should focus on registry systems usability.
New Service Model
Goals
Indicate std version
Support multiple endpoints
Desc non-std i/fs
Clarify assoc between service cap metadata and i/f
Support for std via standardID
Registered as resource
Not mandated: use URI
Put into RofR
Req extension schema
AGREED
Service with capabilities
Structure
Finding services
Add validationLevel as child of Capability
Extra metadata validation reqd
AGREED
Interface: all content data optional except accessURL
Impl may list support for optional or non-std parameters
Interface info in std resource record
Session 2
Applications
Extension rather than 'core'
Goals:
support app-specific metadata
Info on stds & formats
Concepts of desktop app, sw lib, apps called as services
voStandard
Execution environment
Platform: generic
Subtype
Version, …
Data formats
AGREED use MIMEtypes
AGREED for Paul to produce WD for VOApplications
DEFERRED decision on how to replicate such info across registries to final roadmap discussion
CEA Applications
CEA interface: how to define app asynchronously (not discussed here)
App model
Features
Multiple i/fs
Parameters
a number of people were interested in developing apps which would register and be able to be discovered using this extension
AGREED for Paul to produce WD for CEAApplication extension