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