OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

search-ws message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [search-ws] Draft message to SRU implementors group


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

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]