Re: Initial description of Pluggable Content Indexing Serviceproposalsub-proprosal

[Matthew Mackenzie <matt@xmlglobal.com>]

Farrukh,

You're right that the team agreed that CBQ should leverage the 
FilterQuery mechanism, and it will.  In time, I will present a more 
detailed proposal on why I don't think that the Content Indexes should 
be Classifications, and how I propose to change that while still 
leveraging Filter Query.

The "why" is simple.  It just doesn't make sense to think of a content 
index as a classification.  It works for now, but it just isn't right.  
All that needs doing to fix it is to extend the RIM to support a new 
data structure, and Filter Query to support that extension.  What is 
gained in the end is a seperation that benefits a user trying to 
understand the content based query functionality, as well as making it 
much easier for a registry vendor to optimize a Content Index's 
performance.

For version 2, I will replace appendix D with the Pluggable Content 
Indexing Service work + the Classification Index stuff with some notes 
relating general plans for version 3.  If my ideas are not accepted, 
there was no harm done.

Cheers,

Matt
 
> This is a multi-part message in MIME format.
> 
> 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>
> 
> 

-- 
Matthew MacKenzie
Xml Global
http://www.xmlglobal.com