With in mind that SRU and SRW should provide a "lower barrier implementation" I would suggest to keep at least SRU low barrier. When everybody has to support both String and XMLfragment anyway via a parameter there is no need to make it an option. My proposal is: no additional parameter; SRU uses XMLfragment and SRW uses String.
Theo
>>> [log in to unmask] 27-11-02 12:06 >>>
> Date: Tue, 26 Nov 2002 19:33:55 +0000
> From: Robert Sanderson <[log in to unmask]>
>
> Proposal for SRU v1.1
I think this is good work. Nits picked below:
> Title: recordPacking Parameter
> Number: 1
> Date: 26/11/02
> Author: Robert Sanderson
> Scope: New, optional parameters for searchRetrieve operation
I misread this at first as meaning parameters on the searchRetrieve
_request_. It would be more explicit to say something like ``New,
optional <recordPacking> parameter for the searchRetrieve request, and
a corresponding parameter in the response.''
> This string contains the escaped XML of the record in the given
> schema. While this decision was made for good reasons, elucidated
> below, [...]
If I were you, I'd just snip the parenthetical "elucidated below" and
have done. You don't need to justify it -- if justification _is_
required for the current default packing, then this document isn't the
right place for it.
> In order to allow both strings and XML fragments to be returned,
> two new optional fields are required in the service.
Again, I would find this more immediately grokkable if you were
explicit that it's one in the request and one in the response.
> An explain 'default' field
Not necessarily -- see below.
> (1) A new parameter for searchRetrieveRequest called
> <recordPacking>, of type string. This has two valid values,
> 'string' and 'xmlfragment'.
How about, "This *currently* has two valid values"?
> (2) A new field for the record structure, also called
> <recordPacking>, of type string. This has the same two valid
> values, and records the packing type for that record.
Best to say at this point that it is included in the response record
only when it was included in the request.
> (3) An explain 'default' field called 'recordPacking' which records
> which of the two values is the default. It is suggested for version
> 1 compatability this should be 'string' unless there are exceptional
> circumstances.
Since I can't think of any such exceptional circumstances, and since
having to support the remote possibility of such exceptional
circumstances places an additional, unnecessary burden on client
implementors, and since we are keen to avoid ZeeRex bloat for fear
that it will impede take-up, I favour the simpler approach of merely
mandating that records are _always_ packed as strings unless the
client explicitly requests otherwise. Then we can dump this new
explain requirement.
> Compatability and Implementation:
>
> New WSDL would be required to support this extension, but is
> otherwise backwards compatible with SRW v1.0.
You could make this more explicity by replacing "otherwise" with
"on-the-wire".
> If this proposal is approved, new implementers could implement this
> without fear of interoperability issues [...]
Yes.
> [...] so long as they only include the recordPacking field in the
> response when asked for it in the request until version 1.1 is
> finalised.
You don't need to say this here if you've already said it above -- a
narrative sequence that more clearly expounds our thinking.
> Support From:
> Robert Sanderson
Mike Taylor :-)
Thanks, Rob.
_/|_ _______________________________________________________________
/o ) \/ Mike Taylor <[log in to unmask]> www.miketaylor.org.uk
)_v__/\ "Normally Sir, yes. Today, the van broke down" -- Monty
Python.
|