RE: Simple Boolean Query Proposal.

[Krishna Sankar <ksankar@cisco.com>]

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:matt@xmlglobal.com
> Cc: 'duane '; ''mrowley@exceloncorp.com ' '; ''RegRep ' '
> Subject: Simple Boolean Query Proposal.
>
>
> Message text written by INTERNET:matt@xmlglobal.com
> >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.
>