OAI coordination

[Wil O'Mullane]

I voiced similar concerns a while back and would also like to 
see us using types instead of refs. I think when we had this debate before
there were not enough parties deeply enough involved to really understand the
difference.

I also feel the model is spreading a little - perhaps we should now have 
a consolidation phase. Normally in object design we would put all the objects
on the table and then see if we could not merge and get rid of some
while still keeping the extensibility.

Perhaps a topic for the next NVO meeting..

wil

On Wed, Nov 26, 2003 at 08:13:41AM +0100, Gerard Lemson wrote:
> Hi Ray
> 
> > 2.  "root" element for VOResource metadata; that is, the child of the
> >     <oai:metadata> element:
> >
> >     I recommend we use <VOResource>, for the following reasons:
> >
> ....
> >   *  one <Authority> record (see
> >      http://nvo.ncsa.uiuc.edu/VO/schemas/vomdoc-v0.9/VORegistry-v0.2.html#element_Authority)
> >      for each AuthorityID it creates records for.
> >
> >   *  at least one <Registry> record (see
> >      http://nvo.ncsa.uiuc.edu/VO/schemas/vomdoc-v0.9/VORegistry-v0.2.html#element_Registry
> >      that describes itself.  This record should include a listing of all
> >      the AuthorityIDs it manages (i.e. that it has Authority records for)
> >      using the <ManagedAuthority> element
> >
> > No two registries can claim to manage the same AuthorityID.  While this
> > may not remain true in the future, for now, this is the way we track
> > resource records back to their origin (as discussed by Alex).
> 
> Are these proposals, in whatever form they'll end up being adopted,
> going to be formalized in the schema definitions as well ?
> The current schema allows for any of the many (global) elements
> (defined under <xs:schema>) to be used as the root element of a
> valid document. As you say, this makes validating documents a much more
> difficult job, especially if you use some source generator like JAXB or
> Castor for which validation is almost a no-brainer.
> 
> I guess an alternative approach is to say that the current schemas are not
> normative for valid documents sent to/from (registry) services, but that
> separate schemas using the current ones are being created ?
> Is that maybe the idea? I think this fits in nicely with a kind of
> model (the core schemas) vs view (derived, document schemas) approach.
> 
> If not, if the current schemas are defining valid VO documents as well,
> the current design methodology, which heavily relies on using element
> "ref"-s with their required global elements is problematic.
> If you're interested I've created an alternative "port" of your schema's
> that uses element "type" definitions. It carries the same semantics.
> It validates XML documents that are almost identical to those validated
> by the current schemas, but has currently only two global elements,
> VODescription and VOResource. They do moreover have a lower "impedance
> mismatch" with obvious object-data modeling approaches.
> 
> Cheers
> Gerard