[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