RE: XPATH query Take 2

[JP Morgenthal <jp.morgenthal@xmls.com>]

Matt,

The basis for your point is correct, but I invite you to review in light of
what has been said about not implying an implementation.  Your definition
screams of requiring an XML datastore with indexing.

JP 

-----Original Message-----
From: Matthew MacKenzie
To: JP Morgenthal; JP Morgenthal; ''David RR Webber ' '; ''duane ' ';
'''mrowley@exceloncorp.com ' ' '; '''RegRep ' ' '
Sent: 1/7/2001 5:07 PM
Subject: RE: XPATH query Take 2

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.