RofR documentation, status

[KevinBenson]

Couple of comments below.

Ray Plante wrote:
> Hey Kevin,
>
> On Wed, 6 Jun 2007, KevinBenson wrote:
>> One more thing. Your xpath you use in the document:
>> *|capability[xsi:type='vg:Registry']/interface[role='std' and 
>> xsi:type='vg:OAIHTTPGet']/accessURL
>
> Yep--thanks.
>
>> I will ponder a little more about point b.) from what I can see you 
>> get the same results with or without the 'set' parameter, the only 
>> difference is when you don't use the 'set' you might get back a few 
>> more 'Standard' type Resources that are not vg:Registry.  Unless I am 
>> missing something.
>
>  o  Do you recognize that you will get those same vg:Registry records
>     again when you harvest from the other registries?
Yes I recognize that, and from what I can see that is going to happen if 
you harvest with or without the 'set=ivo_publishers'
>
>  o  Do you recognize that the RofR will be among the vg:Registry records,
>     and that if you (blindly) harvest from the RofR again with
>     set=ivo_managed that you will get Standard records again?
>
Yep I recognize that, my intention for a full Registry is simply during 
the harvest cycle to harvest RofR without a 'set' parameter (and use 
'from' except the first time) which as stated by OAI should give me all 
of RofR resources.  For all other publishing registries I will use 
'ivo_managed' the only thing different is to make sure RofR is harvested 
first to make sure if there is a updated vg:Registry in a publishing 
Registry that I will have the most up to date record versus the possible 
out of date RofR one.

I guess it is all of about implementation details so nothing to worry 
about.  I just did not see how the 'set' is really giving you anything 
different except for a special type of client (not a Full registry) that 
does not want the Standard Resources.

> Again, it's okay if you do it this way and deal with the 2 above 
> issues; nevertheless, there is a difference.
>
> cheers,
> Ray