more changes

[Ray Plante]

Hey Kevin,

On Tue, 27 Jun 2006, KevinBenson wrote:
> 1.) (Section 4.2) I was wondering should harvesters detect conflicting 
> "managed" authority ids from different registries and error out and 
> report it.  This is something I have added to our registries instead of 
> making a publishing registry search a full registry to see if it is 
> available.  

Your checking is definitely a good practice, but I think we want to detect 
the error at the source; after all, we want to tell the publisher right 
away, "choose another name because this one's taken" while we have them on 
the line, rather later after the fact.  

> I guess we could do both, but does seem to make a simple 
> publishing registry do extra work.  Possibly you meant that the 
> publisher should go check manually.  I also wonder if RofR could be used 
> in this particular case.

Searching a full registry is probably the easiest way to do this now that 
we have the GetResource() operation.  You give the authority id; if it 
returns a record, you fail; otherwise, you're good.  There is no need to 
parse the results (unlike consulting the RofR).

We could soften the language to say that the publishing registry must 
consult other registries to ensure that the authority ID is not 
already taken; however, the consulting a full registry should be a 
definitive result (barring latency issues) and, in my mind, the easiest 
way to check.  

> 2.) Comment: A few sentences you added says this document does not 
> describe how to discover new publishing registries.  But I would say 
> your the "Note" about RofR sort of implies you can discover new 
> publishing registries.

The Note boxes (as described in the very first Note--I think I made this 
clearer in the last version I sent) are non-normative comments--that is, 
they should not be considered part of the specification, but rather 
helpful comments that help explain the spirit of the spec and how it fits 
into a bigger picture.  

> 3.) Comment: (section 4.3.2 and in schema) maxRecords vg:Harvest 
> probably copied from vg:Search maxRecords.  Might want to say simply 
> "Largest number of records returned" since it is not quite a search method.

Yes, you're right--please fix.  

So where are we on the optional/required harvesting interfaces?  I think 
what you were trying to say was that you would like the harvesters to have 
a choice; therefore, both interfaces should be required, yes?  While I 
tend to agree with Aurelien on this, I think I can live with making both 
required.  (How committed are you to the SOAP version?)

For myself, I'll note that since we first proposed a SOAP version, I've
become less convinced that is it is all that helpful.  In practice, I tend
to think that a SOAP service is usually harder to use than REST
counterparts, but I'll grant that this may be a matter of taste.

Having both will allow us to track the usage of both; it will be easy 
enough to back off from that later if SOAP version is not really used.  

One more thing--a question I've been meaning to ask:  Do you think we 
should make the VOResources attributes (from, numberReturned, and more) 
required in the output to the search operations?  When they matter--that 
is, you're returning partial results--you have to include them for the 
benefit of the client.  When you don't need them, it's trivial to provide 
values.  Making them required, I think will make processing easier on the 
clients (they won't have to program in default values), and it avoids the 
murking problem of when some but not all values are provided.

cheers,
Ray