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.
Agenda
Notes
Links:
Session 1
VOResource basic changes
- Timestamp on created, updated
- xs:dateTime instead of <date>
- Drop 'Z': assume UTC
- AGREED
- also AGREED that both elements should be
mandatory
- Relationships
- Define new relationships types in extension schema
- Will add list of keywords for rel types in doc appendix and registry systems have to code that list validation
- Move webservice Interface sub-type to core schema
- Allows desc of generic ws wo ext schema
- accessURL is the service endpoint
- AGREED
- elementFormDefault="unqualified"
- All terms look like from same namespace
- Throws element name into noname ns
- DEFERRED
- Changes to resource class names
- SkyService -> DataService
- TabularSkyService -> CatalogService
- AGREED
- STC integration
- Contents:
- stc:STCResourceProfile, footprint, waveband
- Issues
- ns is "qualified"
- Cannot index in same way e.g. for searching
- Help for authors
- AGREED
- But need to develop tools
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
- 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 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
- 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