[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [search-ws] Draft message to SRU implementors group
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]