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