RE: [Fwd: Implementation of XML QUERY]

[Scott Hinkelman <srh@us.ibm.com>]

Mark,
The issue is not about the value of adhoc/"structured" query. Hands down
its powerful.
It is about who the actors are and their utilization.

If the group has concensous (which it does seem to have) that adhoc query
is required for
exposure on the inter-enterprise interface then lets all move on with it
-low level as it is-, and realize that
there is further opportunity for companies to work on a more business-level
service on top of it.

Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



"Mark A. Hale" <mark.hale@interwoven.com> on 01/24/2001 04:38:45 PM

Please respond to mark.hale@interwoven.com

To:   ebxml-regrep@lists.ebxml.org
cc:
Subject:  RE: [Fwd: Implementation of XML QUERY]



I appreciate your thinking of me as a super-user.  :-)

I think that my point was mis-interpreted in the comments below.  As I
posted to the list a month ago, there are plenty of tangible benefits to
using both structured queries and ad hoc queries.  Ad hoc queries can
support a super user and it is also a very powerful interface for small,
medium, and large enterprises wishing to do discovery.  Ad hoc queries can
be done against XML elements and the registered content.  I strongly
encourage disbelievers in the ability to use ad hoc query against content
to
try out a wonderful ad hoc query interface already in place:  go to
www.google.com, type "Enterprise Class Content Management" in the entry
field, and hit return.  What is missing is a well defined partner profile
that comes up to do business (I would certainly hope this is achieved in
ebXML).  Notice that I can find someone that can do ECCM without having to
know anything about taxonomies.  Also note that we also have to deal with
the plethora of information that will be available when core components
come
on-line.

We can also visit classical decision theory that suggests that heterarchies
support creativity in early stages of a business life-cycle, which in my
opinion, is the time in which we can foster the growth of new
opportunities.

I am agreement that the discussion about one query syntax over another has
gone on too long.  What I disagree on is the ad hoc versus structured query
debate.  There are plenty of use cases that support both.

To borrow from Krishna: just my two yens worth,

     Have a great afternoon,

     Mark




> -----Original Message-----
> From: David RR Webber [mailto:Gnosis_@compuserve.com]
> Sent: Tuesday, January 23, 2001 7:45 PM
> To: Farrukh Najmi
> Cc: ebxml-regrep@lists.ebxml.org; chetan@pybiz.com
> Subject: [Fwd: Implementation of XML QUERY]
>
>
> Message text written by Farrukh Najmi
> >
> FYI,
>
> In my quest for query experts and their opinions I came across Chetan on
> the xml-dist-app list. Coincidently, it seems that they are discussing
> this issue of late.
> <<<<<<<<<<<<<<<
>
> Farrukh,
>
> It has come to my attention that you are flogging a dead horse here.
>
> Why are we scouring the globe for 'query experts' - whatever they
> may be?  (Will the REAL query experts please stand up - spotlights,
> drum roll, applause).
>
> Frankly, brutally, obviously - this whole debate of foobar query X vis
> barfoo query Y is totally and completely IRRELEVANT.
>
> Can we please stop this now?
>
> The concensus I saw was that we should be describing our
> interfacing in neutral terms, that match the process of discovering
> information via the RIM in simple english language documentation,
> then map those to a set of descrete methods that we publish and
> following that implementors can pick whatever backend
> datastorage system and querying to make that happen.
>
> We have one consistent set of methods for the service API
> that a registry exposes.
>
> Now - Mark Hale pointed out on the TC the other week that
> his experimenting with a UDDI registry that follows this
> approach - that this was not enough for him - he needs true
> ad hoc.  Notice Mark is a super-user, notice Mark is using
> ad hoc to get at all sorts of IMPLEMENTATION specific
> backend details - cos its his job to be a programmer.
>
> That is the whole point.  Programmer = backdoor access to
> internals of registry - probably on a dedicated port via a
> firewall - internal access.
>
> Normal business user - descrete access via industry functional
> suite of services and API - via public URL and open port.
>
> Can we please agree these are two totally different uses.
> That programmers will use ad hoc query in whatever internal
> query syntax the particular backend implementation
> provides.
>
> Public users will have the ability to use a set of RIM service
> API methods that provide "lego bricks" to assemble
> constrainted querying - and that these will NOT use a
> query syntax but instead query syntax agnostic methods
> that provide function + value parameters.
>
> These will also allow static business querying of content
> via business parameter values.
>
> This then is not rocket science - but business basic
> analysis work.
>
> BTW - since I've taught University level SQL and have been
> writing database backend code for twenty years
> and worked on Oracle pre-processor for C and COBOL,
> and worked on Assembler level interface to ADABAS,
> and currently work for a leading vendor of XML searching
> and querying tools, and have a patent for information
> manipulation techniques, and currently on W3C working
> groups.  How come I'm not one of your 'query experts'?
>
> Can you publish your criteria for what is a 'query expert'?
>
> Oh - yes - and can we please ditch trying to use SQL-78
> for implementing XML based registry - well you can if
> you like - but the rest of the world would rather not be
> burdened with this - its rather like telling Frank
> Whittle to design a jet aircraft, and then telling him -
> oh and BTW - the production system will actually
> use a piston engine - because that's what our
> mechanics know how to work on right now.
>
> Respectfully pointing out the obvious in the hope of
> real progress here.
>
> Thanks, DW.