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

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-query message

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


Subject: Re: Initial description of Pluggable Content Indexing Serviceproposalsub-proprosal


Matt,

Thanks for your encouraging words and comments on the brief writeup.

Please find my comments inline. The summary of my thoughts is that we should
articulate the use cases (with priority 1-3) that CBQ is expected to support
and then stick with proposals that address those use cases.

--
Regards,
Farrukh


Matthew Mackenzie wrote:

> Farrukh,
>
> This is a great outline, thanks for spending the time on this.  The
> only issue that this brings up, or rather reminds us of, is that of
> where the indexes are stored.  I brought up an issue during the last
> telecon (not the one on Friday that was only attended by Len ;-) )
> about the indexes being stored as Classification Nodes.  It seemed to
> me that the goal in prescribing this was to find a nook to place these
> things in without modifying the RIM.  This looks a bit like a hack to
> me, something which was meant to be addressed later.

As I recall the team felt (and I agreed) that whatever we do in content
based queries it should
leverage the FilterQuery mechanism to do content based queries. My
assumption is that
it is a good thing and not a hack if our design makes it such that the
result of indexing any
content is that it gets classified using teh existing classification
mechanisms.

However, I am open to the team considering and evaluating any proposals that
fall outside that
envelope of thinking. However, I would look to you to propose something else
and evaluate it
rather than for me to find an alternative.

>
>
> I would like to start a new action item for v3: new structure(s) for
> content indexes.  It could be as simple as having a ContentIndex object
> which holds IndexNode objects.  Underlying implementations could keep
> the indexes in the same physical structures as they do currently (IF
> Appendix D of RS was implemented), just the access methods would need
> to be updated.

I would reccomend that you first articulate which use case would not be met
in the
alternatives on teh table currentlty and then if we agree to the new use
case(s) then you
can take the AI to propose a solution. I would advice against getting into
solutions before
the problem has been agreed upon.

In the absence of the above suggested process it is quite unclear what are
ContentIndex and
IndexNode and what problems they solve.

>
>
> Cheers,
> Matt
>
> > This is a multi-part message in MIME format.
> >
> >
> >
> > In our last meeting I had an AI to write up the idea we discussed for
> a
> > pluggable architecture for
> > a Content Indexing Service for the content based query proposal. So
> here
> > it is:
> >
> > The Content Indexing Service
> > ------------------------------
> > We propose an abstract web service interface in WSDL for an Content
> > Indexing Service.
> > The interface exposes a method called indexContent that allows an
> > arbitrary repository item to be provided to the
> > service for indexing.
> >
> > The indexContent method returns an XML document conforming to the
> > existing ebXML
> > Registry 1.0 specifications that includes indexes in form of
> > Classification instances that index or
> > categorize the repository item.
> >
> > Implementation of Content Indexing Service
> > ---------------------------------------------
> > Any organization may implement one or more Content Indexing Services
> > where each is specialized to index a specific type of repository item.
> > Each
> > implementation of Content Indexing Service is custom tailored for a
> > specific repository item type. For example Encoda Systems may
> implement
> > a Content Indexing Service for indexing videos.
> >
> > Registration of Content Indexing Service
> > ------------------------------------------
> > The solution does not define how an organization that creates a
> Content
> > Indexing
> > Service can publish or register the WSDL for that service within the
> > registry
> > and bind it to a specific type of content. Instead the solution
> assumes
> > that the content indexing service is submitted using
> > the "Registration of Web Services (ROWS)" proposal as being defined
> > within the RAWS sub-team. The
> > ROWS proposal provides first class support for web service
> registration
> > by defining
> > new info model classes called Service, ServiceBinding and
> > SpecificationLink
> > for registration of any web service in a standard way.
> >
> > Details may be found at:
> >
> >  http://lists.oasis-open.org/archives/regrep-raws/200109/msg00000.html
> >
> >
> > Dynamic Content Indexing
> > ------------------------
> > Whenever, a publisher submits a certain type of repository item, the
> > registry checks to see if there is a Content Indexing Service
> registered
> > for that
> > type of repository item. If such a Content Indexing Service is
> > registered,
> > then the registry invokes the service using the registered WSDL
> > description  for
> > the Content Indexing Service. In the invocation, it passes the
> > repository
> > item to the Content Indexing Service and gets back an XML document
> that
> > defines
> > classifications on the repository item.
> >
> > The registry stores the repository item along with the classification
> > information that was dynamically generated using the Content Indexing
> > Web Service.
> >
> > Discovery of Repository Item Based on Dynamic Indexing
> > ------------------------------------------------------
> > The result of the proposed solution is that a registry client can now
> > easily
> > discover the repository items of interest based on dynamically
> generated
> >
> > classification indexes.
> >
> > An interesting aspect of this approach is that we use pluggable web
> > service registration into a registry to index arbitrary content about
> > which the registry has no apriori knowledge.
> >
> > I look forward to your thoughts and suggestions. Matt I will be gald
> to
> > work with you in background to provide more specifics and details to
> > help fit this sub-proposal to the content based query proposal that
> the
> > team is developing for V3. At minimum I expect we will need to spec a
> > WSDL description with a SOAP/HTTP binding. More later.
> >
> > --
> > Regards,
> > Farrukh
> >
> >
> >
>
> --
> Matthew MacKenzie
> Xml Global
> http://www.xmlglobal.com
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
begin:vcard 
n:Najmi;Farrukh
tel;work:781-442-0703
x-mozilla-html:FALSE
url:www.sun.com
org:Sun Microsystems;Java Software
adr:;;1 Network Dr. MS BUR02-302;Burlington;MA;01803-0902;USA
version:2.1
email;internet:najmi@east.sun.com
fn:Farrukh Najmi
end:vcard


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


Powered by eList eXpress LLC