RE: XPATH query Take 2

[Farrukh Najmi - JavaSoft East <Farrukh.Najmi@East.Sun.COM>]

I agree with Matt. I assume that efficient implementations would store metadata
in an RDB or an ODB specializing in XML storage as DOM objects. In the RDB case there would be
a binding between XPATH queries and the RDB schema. I do not anticipate a 
performance issue for queries against indexed content. I am currently investigating
what an XPATH to RDB binding would look like.

--

Regards,
Farrukh

<matt@xmlglobal.com> wrote:
>Date: Sun, 07 Jan 2001 14:07:13 -0800
>JP,
>
>Point taken, however, in the scope of a registry the argument doesn't hold
>water.  The registry has a finite number of xml structures, so
>mapping/translating queries to XPath will be a non-issue.  It is also rather
>naive to think that the query processor will have to load each file into a
>DOM tree and traverse it.  XML indexing systems and databases build indexes
>on elements and paths and handle all of the joins and such that the query
>requires.
>
>If a technology such as LDAP-like drilldown/search was used, how would that
>simplify anything?  The XML would have to be decomposed into organizational
>structures, and indexes would be built transparently across the hierarchial
>data.  Same difference, only not XML-specific.
>
>Cheers,
>
>Matt
>
><<| message from: JP Morgenthal <jp.morgenthal@xmls.com> |>>
>All XPath statement are either relative or absolute.  Relative context
>> require that some absolute positioning was made either through traversal
>or
>> a single instance statement.  Absolute contexts are established by
>> positioning against a root element.  Hence, the same query would have to
>> work against all documents root elements or through a very slow traversal
>of
>> the entire XML document.
>> 
>> My point better stated is that XPath statements are closely associated
>with
>> the vocabulary that is being executed against, which doesn't work against
>an
>> arsenal of diverse vocabularies.
>> 
>> JP
>> 
>> -----Original Message-----
>> From: Matthew MacKenzie
>> To: JP Morgenthal; 'David RR Webber '; 'duane '; ''mrowley@exceloncorp.com
>'
>> '; ''RegRep ' '
>> Sent: 1/6/2001 10:46 PM
>> Subject: RE: XPATH query Take 2
>> 
>> The work done in LDAP is certainly interesting, but what about something
>> like QUILT.  AFAICS, QUILT uses XPath-like syntax which is useful on the
>> document level context while adding functionality to bring it into the
>> same
>> space as SQL.
>> 
>> JP: When you say "root context" what do you mean exactly?
>> 
>> Cheers,
>> Matt
>> 
>> <<| message from: JP Morgenthal <jp.morgenthal@xmls.com> |>>
>> Hello All,
>> > 
>> > I am very pleased that some have seen merit in my argument, however, I
>> would
>> > really appreciate it if someone could identify for me the hesitation
>> to
>> > ignore the work of the LDAP specification.  To my understanding this
>> is a
>> > well accepted standard and has a query facility.  I'm not saying this
>> is
>> the
>> > right direction for us, but it does fit what we are trying to do and
>> is an
>> > existing standard.  
>> > 
>> > There is the issues of extensibilty, and that's where the ebXML
>> Reg/Rep
>> > group could really assist in enhancing an existing standard to support
>> eBiz
>> > repository functions.
>> > 
>> > Until we explore LDAP, however, I don't think we should legitimately
>> look
>> to
>> > technologies that do not immediately suit our needs, such as XPath. 
>> Again,
>> > the point was widely overlooked in my last e-mail that XPath only
>> works
>> > against a single root context.  How are we to reconcile this root
>> context?
>> > XPath has considerable problems allowing users to easily differentiate
>> loops
>> > (consistent types serially declared as siblings).
>> > 
>> > Come on people.  Let's put on our thinking caps here and make sure we
>> select
>> > technologies that are easily implemented and will not require
>> man-months
>> of
>> > rework to make useful.
>> > 
>> > Thanks.
>> > 
>> > JP 
>> > 
>> > -----Original Message-----
>> > From: David RR Webber
>> > To: duane
>> > Cc: 'mrowley@exceloncorp.com '; 'RegRep '
>> > Sent: 1/6/2001 1:15 PM
>> > Subject: Re: XPATH query Take 2
>> > 
>> > Message text written by duane
>> > >First off I apologize for not getting involved earlier inthis thread.
>> > I
>> > have been in the Alps.
>> > 
>> > This point made by JP is paramount and outlines my earlier concerns
>> > dating back to May of this year.  There must be no processing done on
>> an
>> > XML document instance on a Registry Server.  The overhead will kill
>> > ebXML.  The registry is a place to find a document instance.  All post
>> > query overhead must be assumed on the users app.
>> > <<<<<<<<<<<<
>> > 
>> > Duane,
>> > 
>> > Welcome back - I hope your yodelling has improved and the 
>> > vegetarian food was palatable.
>> > 
>> > I have to take you to task here.  There are two conflicting world
>> views
>> > on the TA for ebXML - and you are extolling the V2.0 one here, not the
>> > version 1.0!
>> > 
>> > The initial registry model calls for registry interaction to
>> > predominately
>> > occur prior to runtime.   Therefore support for discovery is
>> important,
>> > and that processing WILL occur on the server.  It will not be high
>> > volume
>> > due to lower user count.  Even in V2.0 the server will be king.  In a
>> > loosely
>> > coupled model you cannot expect all the clients to have installed
>> > software
>> > suites - that's what hamstrings CORBA.
>> > 
>> > Local caching of result sets is the answer to high thru put - not
>> > crippling
>> > server functionality.
>> > 
>> > Anyway - we do however arrive at the same place, and the point that
>> > JP makes I would reinforce.
>> > 
>> > > 3.  We need to be careful as a group not to imply ANY implementation
>> > detail
>> > > for registries.  OQL implies that the data is stored in a fashion
>> that
>> > > supports algebraic joining.  We need to institute and interface that
>> > is
>> > > clearly implementation independent.  Again, I think we need to look
>> at
>> > the
>> > > work of the LDAP group as an excellent example of this.
>> > > 
>> > > That's my story and I'm stickin' to it! :-)
>> > > 
>> > > Regards All,
>> > > JP
>> > 
>> > We cannot prejudge at this point peoples implementations.  We live in
>> > a multi-faceted technology world.   Registry servers will need to
>> > support
>> > a variety of interactions.  Simple XPath derived for certain actions,
>> > then
>> > more sophisticated above that.  Sun wants to choose OQL.  Good luck
>> > to them on that.   I personally think this will limit access to XML
>> > content
>> > down the pike - but for now I'm sure they can engineer something that
>> > will work.  Engineers are resourceful as the XPath 'team'
>> demonstrated.
>> > 
>> > Others are looking at the W3C Query work as the way forward.  My
>> > recommendation is we do NOT lock ourselves into a corner at this
>> > point.   We can easily create an extensible query mechanism with
>> > support for future syntaxes and a sub-set interoperability too.
>> > 
>> >  <query method='XPath'
>> >        action="returnlistURIs"
>> >        classification="\some\query\parameters"
>> >        locator="\specific\instance\criteria"
>> >        mode="allInstances"
>> >        transformation="none" />
>> > 
>> > Ooops - sorry - we are not allowed to think such thoughts as we
>> > don't have time anymore to consider alternate approaches.        
>> > 
>> > For yet another example - see DTD's and Schema.  We started
>> > with DTD's and now GCI are using Schema for parts.
>> > 
>> > Look at TRP they face exactly the same problem - except in 
>> > their space they have wire formats.  MIME or SOAP/XP?
>> > 
>> > Solution?  They are allowing for both - MIME is first pass, 
>> > SOAP/XP is waiting in the wings.
>> > 
>> > We should do XPath right now, and then see as our understanding
>> > improves with early large implementations, and W3C finishes 
>> > both SOAP/XP and their Query work what makes sense then.
>> > 
>> > History sometimes teaches you useful things.
>> > 
>> > DW.
>> > 
>> > 
>> <<| end message from JP Morgenthal <jp.morgenthal@xmls.com> |>>
>> 
>> --
>> Matthew MacKenzie
>> VP Research & Development, Founder
>> XML Global Technologies, Inc.
>> 
>> 
><<| end message from JP Morgenthal <jp.morgenthal@xmls.com> |>>
>
>--
>Matthew MacKenzie
>VP Research & Development, Founder
>XML Global Technologies, Inc.