[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]