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