RE: XPATH query Take 2

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