Re: XPATH query Take 2

[David RR Webber <Gnosis_@compuserve.com>]

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.