[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [search-ws] Draft message to SRU implementors group
I am never one to wish to be standing in the way of progress ;-) If you wish to send it as is feel free to do so, though I prefer if you woukd include an ATOM 1.0 binding explicitly - As you know that is a hot button issue for me and the communities I represent. Thanks. Ray Denenberg, Library of Congress wrote: > We can work all this out, beginning with our call Thursday. The > question now is, is it really necessary to capture this in the note to > post to the SRU list? I can either send it out as is, or wait until > after the call. > --Ray > > ----- Original Message ----- > *From:* Farrukh Najmi <mailto:farrukh@wellfleetsoftware.com> > *To:* 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 5:33 PM > *Subject:* Re: [search-ws] Draft message to SRU implementors group > > > Here are some definitions that may help our discussion. > > * Binding: > o SAML: > <http://www.oasis-open.org/committees/download.php/21111/saml-glossary-2.0-os.html#Binding,%20Protocol%20Binding> > * Profile > o Wikipedia: <http://en.wikipedia.org/wiki/Profile> This is > too restrictive IMHO and does not allow extension profiles > o SAML: > <http://www.oasis-open.org/committees/download.php/21111/saml-glossary-2.0-os.html#Profile> > A little too SAML specific but broader than Wikpedia > o Farrukh's definition: A specification that defines specific > extension and restrictions based upon a core spec that it is > profiling" > > Take a look at the following for examples: > > * > http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss#technical > * > http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security#technical > > > More inline below.... > > Ray Denenberg, Library of Congress wrote: > > In that case let's distinguish between profile and binding. > > - SRU 1.2 is a profile of Search-WS > > +1 > > > - I would argue that openSearch is, similarly, a profile of > Search-WS > > It seems closer to a binding to me since its maps to a concrete > expression syntax but I could call it a profile > > > - An ATOM profile could be called-out by the openSearch profile. We > > could call it an "ATOM binding for Search-WS". But it may be one of > > many; there may be another profile of Search-WS that uses ATOM, but > > uses it differently. > > I see ATOM and OpenSearch as very symmetrical. OpenSearch is a > concrete > expression syntax for requests while ATOM 1.0 is a concrete > expression > syntax for responses. > What is good for one is likely good for another with one > exception. ATOm > is a standard and OpenSearch is not. So we could not have normative > dependency on OpenSearch but could > on ATOM in our specs. > > > So we would want to name these: > > -- ATOM binding number 1 for Search-WS > > -- ATOM binding number 2 for Search-WS > > etc. (more descriptive names) > > You lost me above. There should only be one ATOM 1.0 binding spec. > Not > multiple. Other wise we have chaos. Thanks. > > > --Ray > > > > ----- Original Message ----- > > *From:* Farrukh Najmi <mailto:farrukh@wellfleetsoftware.com> > > *To:* Ray Denenberg, Library of Congress <mailto:rden@loc.gov> > > *Cc:* search-ws@lists.oasis-open.org > <mailto: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 4:42 PM > > *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> > > <mailto: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> > > <mailto: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> > > <mailto: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> > > <mailto: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 > > > > > -- > Regards, > Farrukh Najmi > > Web: http://www.wellfleetsoftware.com > -- Regards, Farrukh Najmi Web: http://www.wellfleetsoftware.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]