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 -----
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>
; 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
|