VOResource v1.0 IWD
Arnold Rots
arots at head.cfa.harvard.edu
Thu Jun 9 14:34:31 PDT 2005
Ray,
A few comments.
In Section 2.2 you define UTCDateTime. I think it is the only place
where you use a union and I wonder whether that is a good choice.
It is obviously tempting, but my impression is that code generators
are not universally happy with it since it makes for a rather
indeterminate polymorphism.
As part of that union you define UTCDateTimeZ. I would advise against
it. The "Z" option has explicitly been excluded from STC and from
FITS since the whole time zone philosophy in ISO 8601 is totally
inadequate for astronomical purposes. I am aware that that does not
play a role here, but I would suggest that consistency within the VO
is more important. Therefore I would suggest to drop the Z and assume
UTC by implication (it's in the type name anyway).
Ah well, I have to make a comment on the bullet in Section 2.3 that
deals with substitution groups. xsi:type is not completely
functionally equivalent to substitution groups; there are a few
differences. I am not sure that it is terribly important to make it
obvious in the documents that a substitution has been made; I think it
is far more important in the schema - and there a substitution group
provides a more obvious flag.
I know you have reservation about substitution groups, and I share
most of them, but there are certain things that one can do with SGs
that xsi:type does not allow.
Near the end of 2.3.1 you talk about sharpening the meaning of a
vr:Resource. To me, "sharpening" conjures associations with
"restriction", not "extension" or just a name change. And I must say
that I am not terribly comfortable with the concept of identical types
that supposedly have different properties, implied by the name of the
type.
Restrictions are problematic, but they are also useful.
As to the last sentence of this section: again, yes, it is less
obvious, but does it matter?
In 3.1.2, under vr:Date Attributes, I find a value "representative"
for "role". This is mixing apples and oranges. The coverage is not a
part of Curation. Creation and update are fine, but don't mix in any
coverage.
In 3.1.3, under vr:Content metadata elements, I find source and
referenceURL. Are these really different beasts, other than that one
is a URL and the other <somethingElse>? Or maybe I don't see how one
extracts a resource from a bibliographic reference. If they are the
same, there is no reason to dinstinguish them; a bibcode can be turned
into a URL or a URI.
It struck me that the allowed values for the contentLevel are pretty
USA-centric - at least Middle School and Community College are.
- Arnold
Ray Plante wrote:
> Hey RWGers,
>
> You may have noticed that I have recently posted an internal working draft
> of VOResource v1.0 at
> http://www.ivoa.net/twiki/bin/viewauth/IVOA/VOResourceV10. Everyone
> interested, particularly those that run registries, are encouraged to
> review this draft.
>
> Unlike previous releases, this version comes in two forms: a prose
> specification document, which will eventually be submitted through the
> standards process, and the official VOResource schema. Your comments on
> both would be very valuable.
>
> Also different from previous releases is that it only includes the core
> VOResource schema. From now on, the other extension schemas will be
> released independently. The idea is to settle the core and push it
> through the standards process before attempting to standardize the
> extensions.
>
> Our roadmap has us scheduled to release the external Working Draft July 1,
> so it would be good to get all but the most minor changes in before then.
>
> cheers,
> Ray
>
>
--------------------------------------------------------------------------
Arnold H. Rots Chandra X-ray Science Center
Smithsonian Astrophysical Observatory tel: +1 617 496 7701
60 Garden Street, MS 67 fax: +1 617 495 7356
Cambridge, MA 02138 arots at head.cfa.harvard.edu
USA http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------
More information about the registry
mailing list