[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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> ; 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> ; 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>; 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> ; 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>; 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]