Subject: RE: Simple Boolean Query Proposal.
Hi, This looks simple enough to implement - an implementer could even translate this to a SQL if they want it. David, did you produce any artifacts out of the NIST (query) work you mention in this e-mail ? On a related note, Matt, are you of the opinion that the regrep facilitate with basic/core query building blocks/primitives and the vendors can choose to implement adaptors (OQL,SQL,XML-Query) over those primitives ? cheers > -----Original Message----- > From: David RR Webber [mailto:Gnosis_@compuserve.com] > Sent: Sunday, January 07, 2001 3:39 PM > To: INTERNET:firstname.lastname@example.org > Cc: 'duane '; ''email@example.com ' '; ''RegRep ' ' > Subject: Simple Boolean Query Proposal. > > > Message text written by INTERNET:firstname.lastname@example.org > >Fine by me. XPath is easier to learn than QUILT, and I think > XPath would do > just fine. > > Now for something different..... > > Why wouldn't ebxml regrep simply define a set of calls which allow a > user/app to search for certain things? The UDDI initiative did this with > their find_*() methods. If the group were to do this, there > would be no QL > holy war as vendors could use whatever technology that they are married to > to fulfill queries. Vendors could extend the core to perform more complex > queries (they will anyway). > > Comments? > > -Matt< > > >>>>>>>>>>>>>>>>>>>>>>> > > Ok - Matt - remember what was published 4 months ago? > > This is based on work Mike Kass at NIST and I did, > and from that Smithsonian query application that had to be > database agnostic. > > Also - if you go to http://www.monster.com - there are 445,000 > job vacancies - so this equates pretty good to a directory > of 445,000 businesses that need something, or have a > speciality. > > Of course they are using HTML searching style right now. > But ad hoc querying it is. > > Let's re-visit and see what people reckon on a best approach > given what we've learned in the last four months. > > All this XPath / XSL / techie detail is well and good - but how > about the actual business requirements here??! > > The main reason I see that Farrukh wanted to do OQL was so > that we could head off UDDI and do ad hoc queries against > CPP company profiles in the ebXML Registry. > Do we really need complex searching technologies here to > get the business job done? > > On inspecting Monster.com - my assertion would be - > we can get away with a simple boolean search first pass > and get 95% of the business functionality - if not 100%! > > What is a simple boolean search? > > 1) Locator + comparitor + value = query term(s). > > a) Valid Locators: > > (i) A tag name (any path context) > (ii) Tag root path (specific path context) > (iii) GUID or UID or URN > (iv) "*" = match any text (HTML style on content) > > 2) Valid Comparitors: > > (i) EQUALS-STRING > (ii) EQUALS-DATE > (iii) LESS-THAN > (iv) GREATER-THAN > (v) IS-EARLIER-THAN > (vi) IS-LATER-THAN > (vii) CONTAINS-STRING > > These are based on the OASIS registry query list drafts. > Notice if you wanted to do a subset we could lose > 3 of these that are date specific and do string > comparisons only - since current > XML is not typed on dates. Given that we're > looking for businesses a la UDDI this is most > likely acceptable - for version 1.0 here. > > 3) Value = string or datestring (YYYY-MM-DD only) > > 4) Valid joins - OR, AND; NOT OR, NOT AND > > Now to insert these into the DTD's for registry access > you simply need to add: > > <!ELEMENT RequestItem (RegistryItem)> > <!ATTLIST RequestItem > Action (queryURI | queryContent | queryRAW ) #REQUIRED > > > > <!-- Allows specification of Registry information model --> > <!-- compliant references to actual content. --> > > <!ELEMENT Locator (term+)> > > <!ELEMENT term EMPTY> > <!ATTLIST term > tagpath CDATA #REQUIRED > tagmode CDATA ( TAG | PATH | GUID | UID | URN | ANY ) #REQUIRED > operator (EQUALS-STRING | CONTAINS-STRING | IS-EARLIER-THAN | > IS-LATER-THAN | GREATER-THAN | LESS-THAN ) #REQUIRED > value CDATA #REQUIRED > join CDATA ( OR | AND | NOT OR | NOT AND | END-QUERY ) #REQUIRED > > > > A sample query term would then be: > <requestItem > Action="queryURI"> > <RegistryItem/> > </requestItem> > <locator> > <term tagpath="country" tagmode="TAG" > operator="EQUALS-STRING" value="FRANCE" > join="AND" > > <term tagpath="grape" tagmode="TAG" > operator="CONTAINS-STRING" value="MERLO" > join="END-QUERY" > > </locator> > > Since Farrukh already has implemented a set of functions > to retrieve context (drilldown), that will give you the > Tag Name or Tag root path or GUID/ UID - this is it. > > A couple of pages in the spec' and its done. Use what > ever backend storage database technology you want. > > Any questions?! > > Thanks, DW. >
eList eXpress LLC