[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [search-ws] Draft message to SRU implementors group
IMHO, there needs to be at least one profile spec that covers each of the following in the immdeiate future: * OpenSearch binding for Search-WS requests * ATOM 1.0 binding for Search-WS response * SRU 1.2 Profile for Search-WS (which may or may not refer to previous two profiles - that would be up to that profile) In addition there may be a need for the following in a more distant future: * SRU 2.0 Profile for Search-WS (which may or may not refer to previous two profiles - that would be up to that profile). This really should depend upon completion of SRU 1.2 profile IMHO Thanks. Ray Denenberg, Library of Congress wrote: > No, I think he was suggesting that ATOM be added to the list of profiles. > There is no "list of issues for SRU 2.0" unless you consider it to be > the one-item list, "proximity". > --Ray > > ----- Original Message ----- > *From:* LeVan,Ralph <mailto:levan@oclc.org> > *To:* Ray Denenberg, Library of Congress <mailto:rden@loc.gov> ; > search-ws@lists.oasis-open.org > <mailto:search-ws@lists.oasis-open.org> ; Robert Sanderson > <mailto:azaroth@liverpool.ac.uk> > *Sent:* Monday, December 10, 2007 3:55 PM > *Subject:* RE: [search-ws] Draft message to SRU implementors group > > Sorry, I don’t follow the connection between Atom (a possible SRU > 2.0 response format) and CQL (a query language). > > All I was saying was that Farrukh’s suggestion that you add the > Atom response format (Feed) to the list of issues for SRU 2.0 was > okay by me. > > Ralph > > ------------------------------------------------------------------------ > > *From:* Ray Denenberg, Library of Congress [mailto:rden@loc.gov] > *Sent:* Monday, December 10, 2007 3:52 PM > *To:* search-ws@lists.oasis-open.org > <mailto:search-ws@lists.oasis-open.org>; Robert Sanderson > *Subject:* Re: [search-ws] Draft message to SRU implementors group > > I see the "ATOM profile" as a different animal. It is not a > profile of the core spec, rather it is a profile of the ATOM spec. > Similarly, I think we need to profile CQL. > > In other words we would write a profile of CQL, and a profile of > ATOM, and these would be referenced by other profiles - profiles > of the core spec. In fact there may need to be several CQL > profiles. Possibly more than one ATOM profile. > > Now we don't really have all of this sorted out. Not to say that > we even have the easy part sorted out, but we don't even have > vocabulary yet to characterize what we're talking about here. > > Do you really want me to try to cover this in the message? > > Opinions? > > --Ray > > ----- Original Message ----- > > *From:* LeVan,Ralph <mailto:levan@oclc.org> > > *To:* Farrukh Najmi <mailto:farrukh@wellfleetsoftware.com> ; > Ray Denenberg, Library of Congress <mailto:rden@loc.gov> > > *Cc:* search-ws@lists.oasis-open.org > <mailto:search-ws@lists.oasis-open.org> ; Robert Sanderson > <mailto:azaroth@liverpool.ac.uk> > > *Sent:* Monday, December 10, 2007 3:27 PM > > *Subject:* RE: [search-ws] Draft message to SRU implementors group > > I disagree with Farrukh's call for caution. I'd leave that part as > written. > > I have no objection to adding Atom 2.0 to the SRU 2.0 issues list. > > I think that's a well crafted message Ray. > > Thanks! > > Ralph > > -----Original Message----- > From: Farrukh Najmi [mailto:farrukh@wellfleetsoftware.com] > Sent: Monday, December 10, 2007 3:08 PM > To: Ray Denenberg, Library of Congress > Cc: search-ws@lists.oasis-open.org > <mailto:search-ws@lists.oasis-open.org>; Robert Sanderson > 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 > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS > TC that > generates this mail. You may a link to this group and all your > TCs in > OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > -- Regards, Farrukh Najmi Web: http://www.wellfleetsoftware.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]