In that case let's distinguish between profile and
binding.
- SRU 1.2 is a profile of Search-WS
- I would argue that openSearch is,
similarly, a profile of Search-WS
- 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. 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)
--Ray
----- Original Message -----
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>
; 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
|