RE: Review of thoughts on Ad Hoc Queries

["Nieman, Scott" <Scott.Nieman@NorstanConsulting.com>]

>>Foreinstance I see the OASIS/NIST approach as basically a 
container in XML.  Nothing more.  It serves to deliver a 
simple set of locator terms.   It does not mandate any
particular query syntax.

I am considered about interoperability between distributed registries here.
a canonical form enables distributed registries, whereas I could get back an
ebXMLError stating "Query Syntax not support" from one registry instance,
whereas a successful result from another.  I ultimately would like to
publish a query to n registry instances and get n successful results back
NOT n-e where e is the number of error messages.

>> Then e) is a vital piece. OQL was never designed to work
with returning pieces of XML content.   We saw this 
shortcoming from the PoC in Tokyo - returning URL's to
the actual content instead of the content itself.  And then
there are slices into the content within nodes - one of the
key points of tree heirarchies and XML itself.  Providing
this is a mandatory need - and I believe part of what
CC is asking for in their analysis to be able to group
XML content returned.

Certainly like this, especially if it makes others happy.

>>My sense is we are much closer than we were five days ago, and that
a few more days are worth spending at this point.

OK.   I will cap this at Friday.  Since we are NOT in a f2f, I recommend the
OASIS reps propose the replacement language with examples, and any necessary
support information (similiar to the XPATH virtual document view approach)
that would go into the appendix.  NOT a completely new document, JUST ONE
chapter and maybe an appendix section.

Regards,

Scott




-----Original Message-----
From: David RR Webber [mailto:Gnosis_@compuserve.com]
Sent: Tuesday, January 09, 2001 9:12 AM
To: Nieman, Scott
Cc: ''ebxml-regrep@lists.ebxml.org ' '
Subject: RE: Review of thoughts on Ad Hoc Queries


Message text written by "Nieman, Scott"
>
Should we have a straw vote on the OASIS 12/20 query approach vs. XPATH vs.
OQL?  If so, it needs to be discussed, detailed with mappings to the RIM,
then voted upon based on analysis.  these mappings could make the RS
document more complicated.  

e.g.,

Syntax            Mapping to RIM
OQL               Direct
XPATH             Requires creating virtual document views of RIM
OASIS             ????

It took us one full day to do this for XPATH, will it take another f2f for
the OASIS approach????

Regards,

Scott<

>>>>>>>>>>>>>>>>>>>

Scott,

Thanks for the assessment here.

I think we've so far been missing something vital here - what
Farrukh calls a 'breakthrough' or two.   It's tough getting everything
down on email - or even articulating this stuff clearly on calls
or in meetings sometimes.  Sometimes it takes a while for
everyone to understand all the nuances and facets.

Foreinstance I see the OASIS/NIST approach as basically a 
container in XML.  Nothing more.  It serves to deliver a 
simple set of locator terms.   It does not mandate any
particular query syntax.

In following this theme in the proposal I posted, I allowed
for four different locator terms. 

a) Simple XML tag + operator + value

b) XPath locator (path/node expression only) + operator + value

c) Specific focused queries on GUID, UID, URN, etc.

d) ANY = HTML style - I don't care about context - show me all
     hits.

e) ability to specify returned content mode.

The difference is that this avoids the complex XPath extensions
in favour of just the nodes and paths piece.

Why would we do all this?   What I see is that d) is the defacto
standard for the Web today.  By doing a) and b) we are giving
people a better pair of tweazers to pick the right piece with.
However we are avoiding the complexity of %like% (can I say
I do not see anything to like about %like% for our business
use?)

Then c) is the obvious focused queries that we can clearly
see are needed.  What c) overcomes is the need to write
complex joins and other cascading queries - because we 
can go straight to the right pieces.   As Farrukh noted this
works because registry is not a collection of random 
content - but content with classification with GUID and UID
associations - and exploiting this directly allows us to 
significantly lower the bar in terms of complex generalized
searching algorithms.  Simply put - we do not need OQL 
at this time to get us a functional registry.  Most especially
when - by Farrukh's own criteria - the need is to be able
to implement registry with even simple XML flat files
a XML parser and sub-directories at the bottom most level.

Then e) is a vital piece. OQL was never designed to work
with returning pieces of XML content.   We saw this 
shortcoming from the PoC in Tokyo - returning URL's to
the actual content instead of the content itself.  And then
there are slices into the content within nodes - one of the
key points of tree heirarchies and XML itself.  Providing
this is a mandatory need - and I believe part of what
CC is asking for in their analysis to be able to group
XML content returned.

OK - that said - do we need to take two days here and 
some of us work on a short few pager draft that spells
this out in more detail?  Including a set of access models
based on the RIM we feel we need (classification -> content
locations, and content <-> content associations, et al).
I'm still not clear on that part especially.  And this seems
to be the heart of the matter.   What is the level of complexity
we need and why?

Maybe we could break this down.  We could do that bit
first, and then look at the three approaches, OQL, XPath,
and containered focused querying (CFQ).  
Notice that CFQ extends the simple OASIS model to
fit the ebXML RIM and requirements.  My sense is we
are much closer than we were five days ago, and that
a few more days are worth spending at this point.

Also five days ago we were struggling for clear examples
in XML of content.   I'm not sure we have that solved yet.
Have we taken say the CPP for example, added
some classification structure for them, added
GUID and UID references to some sample company
registrations XML content, and then run some business
case queries - \industry = 'plumbing'  AND \city='Cleveland'
thru to sanity check it all?

Let's clearly understand the alternatives here - I'm not
sure reading all that's been presented thus far that I
yet do.

Thanks, DW.