RE: XPATH query Take 2

[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.