Re: [search-ws] Draft message to SRU implementors group

[Farrukh Najmi <farrukh@wellfleetsoftware.com>]

This looks mostly good Ray. Some comments that are hopefully 
non-controversial inline below...


Ray Denenberg, Library of Congress wrote:
>  
> Draft message. Please comment.
>  
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>  
> At last week's teleconference of the OASIS Web Services TC, we agreed 
> to the following strategy: We will develop a base, or core, 
> specification - an abstract model from which 
> serializations/profiles/bindings/extensions/specializations will be 
> developed. 
>  
> We haven't yet decided on terminology:  base specification, core 
> specification, or abstract model; serialization, profile,  binding,  
> extension,  or specialization.  (For the latter set, several of these 
> terms may  be used with different meaning.)  Temporarily we will use 
> "core specification", and use "profile" and "binding" interchangeably.
>
> The core specification will leave open nearly all possible choices. 
> For example, parameters will be defined but not characterized as 
> mandatory/optional/repeatable.  In some cases a parameter may be 
> defined though its name might not be specified (for example, the query 
> parameter).  A profile may then specify that a given parameter may be 
> mandatory or optional, repeatable or not-repeatable, must not occur, etc.

Perhaps it would be prudent to not go to the other extreme ( "leave open 
nearly all possible choices") and instead simply "leave open all 
controversial choices"?
We should still try and reach consensus on as much as possible that is 
non-controversial and try and mandate it in the core.

>  
> This effectively renders moot some of the discussion we have been 
> having, at least as far as the core specification is concerned. The 
> core specification will not prescribe a concrete response format, so 
> the issue of which response format will be mandatory, and the issues 
> surrounding ATOM, do not apply to the core specification.  Of course 
> it doesn't mean the issues go away, they just get pushed down a 
> level. However, different communities can make different decisions - 
> one profile might ignore ATOM altogether while another might make it 
> the sole response format. Query type issues also become moot at the 
> core specification level. Different profiles will specify different 
> query types.
> So, two products implementing the core specification may or may not 
> interoperate. Their chances increase if they both implement a common 
> profile, and increase further if they both implement a common 
> specialization of that profile, and so on. And of course two products 
> implementing different profiles might not interoperate at all, but 
> it may be that they are not meant to interoperate, their applications 
> are different. In any case the level of interoperability is ultimately 
> decided by business needs. If profile A calls out the SRU response 
> format and profile B calls out ATOM, there is nothing to stop an 
> implementor from supporting profile A and profile B in a product.
>
> Some profiles will be developed within OASIS as part of this 
> committees work, others within OASIS outside this committee,  and some 
> in other standards groups or communities. The number of profiles to be 
> developed is difficult to estimate at this point, but there will be at 
> least three to start with: SRU 1.2, OpenSearch, and SRU 2.0. 
>
> SRU 1.2
> The next order of work for the Committee will be to draft the core 
> speccification and the SRU 1.2 binding. This will serve as proof of 
> concept.  So the SRU 1.2 binding will be done within the committee.
>
> OpenSearch
> This will also be done within the Committee. We will enlist OpenSearch 
> experts to work with us on this. It may be that the OpenSearch 
> specification itself will be formalized as an RFC within IETF.  
> That would occur independent of OASIS, and our work would be to write 
> a profile which would simply be a binding to the RFC.  Before the RFC 
> work is done we might write a temporary binding to the existing 
> OpenSearch specification.
>
> SRU 2.0
> The original idea behind this OASIS committee was to work on the 
> difficult problems of SRU (proximity, for example) and the resulting 
> standard would be a major revision of SRU (in contrast to a minor 
> revision, for example, moving from 1.1 to 1.2 where the changes were 
> minor, did not require a formal process, and was done within the SRU 
> implementor group), i.e. SRU 2.0.  It was also originally envisioned 
> that SRU 2.0 would incorporate OpenSearch.  Although this is a 
> different direction, there is still a need to develop SRU 2.0 - 
>  separate from OpenSearch, but under a common framework.

Please aslo add "ATOM 1.0" profile to above list. Thanks.

>
> Where the work on SRU 2.0 will be done is an interesting (and open) 
> question and there will probably be much discussion. Wherever it is 
> done, within OASIS, within a different standards group (NISO, for 
> example) or simply within the SRU implementor group: (1) if not done 
> as part of this committee's work, the Committee nevertheless needs to 
> stay close to the effort to be sure that we don't end up with a result 
> that is not compatible with the core specification; and (2) if not 
> done within the the SRU implementors group, that group nevertheless 
> need to participate actively in the development.
>
> Probably there will be very little or no new technical discussion 
> initiated by the Committee on this list for a period while we sort out 
> these questions, and develop a draft of the core specification and 
> binding to SRU 1.2. When these documents are drafted they will be 
> submitted for review.
>  
>  
>  


-- 
Regards,
Farrukh Najmi

Web: http://www.wellfleetsoftware.com