RE: A DBA perspective.

[Bob Sutor <rss@sutor.com>]

If you have an API, why do you want to say anything about
how it might be implemented beneath the covers?

Bob Sutor

-----Original Message-----
From: David RR Webber [mailto:Gnosis_@compuserve.com]
Sent: Wednesday, January 10, 2001 12:10 PM
To: ebxml repository
Subject: A DBA perspective.


This morning a explored the thought - 

 'How would a DBA do all this?'.

And then I reviewed Farrukh's XML and XSL examples
on XPath.

The two appeared to be heading to the same point
in time and space (attached corrected XML file BTW).

What I did notice too - is that the XPath approach was
dictating a lot of element content that I'm not at all
sure I'm confortable with - but as you will see shortly
this will no longer be an issue.

Ok - a DBA #1 would not open up their datastore to
generalized queries from Joe Public!   This opens
up too many security and content access issues.

Instead they offer a set of customized stored procedures
and grant access rights to run them.

Quite simply this is the way to go!   Farrukh's little list of
XSL scripts is already mapping out a set of procedures.

Now - notice if we marry this to the containered query 
approach - we get a simple abstraction layer - and
BEST OF ALL - we no longer care about what 
query syntax is being used!  Finally we have a 
simple model and get ourselves out from underneath
trying to microengineer this.

i.e. We simply state what the access functions are, 
       and what parameter values they accept, and
       develop these from the business use cases.

Lots of other good things start falling into place.
We create sets of procedures based on the 
RIM and our use case models - and group
them accordingly.  Now implementors can
build to support these, conformance testing
can validate them, and the long term we can
extend the sets as feedback indicates nice to
have others.   And we can groups sets into 
'Must haves', 'Nice to haves' and 'Vendor / Industry
extensions'.   We can even build a classification
scheme so we can discover these online via
drilldown and long term get out from under even 
having to manage the list of procedures!

And we get out from under having to recommend
lowlevel storage structures!!  Even better - we really don't
care how the information is stored internally - so
long as the prescribed procedures return the 
right results to the information model.

OK - how do we implement this all?  Turns out
its a simple extension to the model I already
posted - adding a new type of 'PROCEDURE' to
the query list, and then extending the <value> block
so that it can becomes values(value+).

Here's the updated DTD and sample, and 
a first cut at a list of RIM Procedures and Groups.

RIM Procedures

o  Classification

- getClassifedObjects
- getClassificationTree
- getRootClassificationNode

o  Association

- getAssociatedObjects
- getObjectsByExternalLink

o  Content

- getObjectByName

o  Package

- get ObjectsByPackage

o BusinessFunction

- getSupplierCPP
- getObjectsByOrganization
- getObjectsByIndustryClassification

o RegistrySupport

- getRegistryFunctions
- getRegistryTRP

and here is the supporting XML:

The ebXML Registry Ad Hoc Query Accessing 

Pass an XML command container that consists
of:

1)  Locator + comparitor + (value | valuelist) = query term(s).

     a) Valid Locators:

         (i)   A tag name (any path context)
         (ii)   Tag root path (specific path context)
         (iii)  A supported Registry Procedure name.
         (iv)  GUID or UID or URN
         (v)  "*"   =  match any text  (HTML style on content)
       
2)  Valid Comparitors:

         (i) EQUALS-STRING 
         (ii) EQUALS-DATE
         (iii) LESS-THAN
         (iv) GREATER-THAN
         (v) IS-EARLIER-THAN
         (vi) IS-LATER-THAN
         (vii) CONTAINS-STRING
         (viii) MATCH

   These are based on the OASIS registry query list drafts.
    Notice if you wanted to do a subset we could lose
    3 of these that are date specific and do string 
    comparisons only - since current
   XML is not typed on dates. 

3) Value = string   or datestring (YYYY-MM-DD only)

4) Valid joins - OR, AND;  NOT OR, NOT AND

Now to insert these into the DTD's for registry access
you simply need to add:

<!ELEMENT RequestItem (RegistryItem)>
<!ATTLIST RequestItem
  Action (queryURI | queryContent | queryRAW ) #REQUIRED
>

<!-- Allows specification of Registry information model -->
<!-- compliant references to actual content.            -->

<!ELEMENT Locator (term+)>

<!ELEMENT value (#PCDATA)>
<!ELEMENT values (value+)>

<!ELEMENT term (value | values)>
<!ATTLIST term
  tagpath CDATA #REQUIRED
  tagmode CDATA ( PROCEDURE | TAG | PATH | GUID | UID | URN | ANY )
#REQUIRED
  operator (EQUALS-STRING | CONTAINS-STRING | IS-EARLIER-THAN |
            IS-LATER-THAN | GREATER-THAN | LESS-THAN | MATCH ) #REQUIRED
  join CDATA ( OR | AND | NOT OR | NOT AND | END-QUERY ) #REQUIRED
>

A sample query term would then be:
 <requestItem
    Action="queryURI">
    <RegistryItem/>
 </requestItem>
 <locator>
    <term tagpath="getObjectsByIndustryClassification" tagmode="PROCEDURE"
                operator="MATCH"
                join="AND">
       <values>
             <value>GROCERY</value>
             <value>DRINK</value>
             <value>WINE</value>
        </values>
    </term>
    <term  tagpath="country" tagmode="TAG"
           operator="EQUALS-STRING"
           join="AND" >
      <value>FRANCE</value>
    </term>
    <term  tagpath="grape" tagmode="TAG"
           operator="CONTAINS-STRING" 
           join="END-QUERY" >
           <value>MERLO</value>
    </term>
 </locator>