more changes

[KevinBenson]

A couple of comments and questions in-line and at the bottom.

Ray Plante wrote:
> 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.  
>   
Yep  I started thinking more about the GetResource and the fact that you 
must define a vg:Authority type.  This is something I did not enforce in 
the past (hence I let them add to the vg:Registry type 
managedAuthority), but would be good to.  So okay agreed publishing 
registry to call full registry.  Though possibly a note to say calling 
GetResource on the authority id is a good way to discover if the 
authority id is already in use.
>   
>> 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.  
>   
I see what you mean, but it does seem strange considering this was the 
whole reason of RofR to be created.   How about we simply move the 2 
sentences "Note that this document does not specify how a registry 
obtains....."  Into the Note section? after all the sentence starts with 
the word "Note" :)
>   
>> 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
>   
Yeah I am in the same area, I am less convinced as well.  I tend to like 
the REST interface.  We will still supply both SOAP and REST (though our 
SOAP Interface is nothing more than like a proxy whereby it calls the 
REST interface and does a little SOAP wrapping)

Ahha yes I am glad you saw that, those attributes are meant to be required.

Question/Thoughts: In OAI the child of "metadata" is an "any" element 
with "any" namespace curious if that will cause any client problems?

Question:  I remember the child of "metadata" being different between 
some registries and this caused a few problems.  I currently try to fix 
it via an XSL stylesheet.  But in the end our Registries sort of got 
in-sync and used a <vr:Resource...>  as the child element.  Wondering 
would it be good to actually say or specify this in the RI document to 
avoid any possible problems or confusion.  I don't think i saw it in there.

cheers,
Kevin


>
>