[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: A DBA perspective.
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>
Powered by eList eXpress LLC