RE: vOTE CALL: RE: Counter Proposal Paper Draft 0.9

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

Waqar,

Combining responses here - and also including in Scott H.
good points on , see my thoughts interspersed.

Thanks, DW.

Message text written by Waqar Sadiq
>
Tryign to further understand your proposal, can you clarify how would I
query the meta data of RIM where the query needs to be predicated over
multiple attributes?  So for example, how would I need to  retrieve a
specific version of a managed object whose name has some text in it.

>>>>>>>>>>> The method model supports <findValues> in the 
XML query - and this is designed to let implementers provide an
arbitary number of value(s), so you could easily have a findValue 
pointed at <versionID> and specify an exact matching - with a 
default of 'latest', and of course select multiple attributes.
If you wanted to tie attributes to a value, we could add an
<attributes> block to <findValue>, and then within that:

<findValue value="Sometext">
    <attributes>
        <attribute attrname="size" attrvalue="10"/>
    </attributes>
</findValue>
   
<<

The problem is that soon as you recognize the need to query multiple
attributes, you have a combinatorial explosion which would be difficult to
handle with a API based approach.  At the same time, I sympathize with your
concern about execution of poorly formulated queries becoming an unneccasry
burden on registry implementations.  That is why, personally I am in favor
of supporting SQL syntax with constraints on the SQL so that features of SQL
which are not necassary will not be supported.  Just, and strictly, as an
example, the specification may say that joins will not be allowed or the
keyword DISTINCT will not be supported e.t.c.
<
>>>>>>>>>>>>>>>>>>>>>>

OK - I believe that focusing on the business functional is the answer to
avoid the combinational explosion issue, and providing a sensible set
of defaults and an extended parameter values.   IBM's JCL is a point in 
case - not too many functions - each one taking lots of parameters, and
focused on a specific business need.

Then on the SQL side - of course as a vendor of an XML query tool - we
are seeing that SQL has major limitations! ;-) Anyway - Scott's point 
below - if people want SQL for their implementation - we should not
be blocking them... I believe it does highlight the different models
here - I'm seeing the SQL or foobarXXX will be written by the DBA or
backend analyst - and NOT the enduser.  As such each Registry can
provide WHATEVER query syntax it likes to those people.  What we need
to provide is a consistent wrapper for those once they are done,
setup the method and pass the required values to them.  Machine
APIs will not write SQL interactively however!! (Machines are not yet
that smart).  So - custom queries that have been pre-defined work
well for machines.  Also - the machine wants a simple consistent
API to these - not access to the lowlevel internals.

So each registry can expose exactly the same API interface, method,
values, and it becomes easy for the machine to query whatever 
Registry has that enabled.
<<<

Message text written by Scott Hinkelman
>"How" obviously would have to be worked out by the group. Yes it would not
easy with a threat of too-generic results,
but with potential trade-off of durability over time. The group has already
focused at the information model level, not
specifically at the 'Business' level (as DW pointed out with comments about
"...but we could define the Business API....")
so working at the information level is assumed; and then adhoc query
becomes appropriate since you know
the backing model. Hence, since we are talking more at the
information-level in ebXML vrs 'Business-level' and
I question why support only one information query language.<
>>>>>>>>>>>>..