RE: XPATH query Take 2

[Matthew MacKenzie <matt@xmlglobal.com>]

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.