RE: [xsl] Paradigm clash between XML as document and as database

[Benjamin Franz <snowhare@xxxxxxxxxxx>]

On Wed, 31 Jan 2001, Christopher P. Wang wrote:
> 
> You may want to check out the Tamino database product from Software AG.

I did. It appears document-centric: They provide indexes to *find*
documents for their own query language and some internal (non-XSLT)
transformational output - but not to accelerate XPath/XSLT in general as
far as I can tell. Additionally, documents are stored as units. They have
a servlet that fakes by node updating - but it apparently actually reads
and writes the whole document to do it. I am still talking with them, but
I am not especially hopeful about it.

Here is part of an email exchange I had with Tamino a few days ago:

---

 Q1) You have indicated that Tamino has conformant support for XPath and
     XSLT. Just as a confirmation again, this support is fully compliant
     with the W3C's Recommendations for each as defined
     in <URL:http://www.w3.org/TR/xslt.html> and
     <URL:http://www.w3.org/TR/xpath.html>, correct? If not, in
     what significant aspects is it non-compliant?

 A: Concerning XPath, ther are two different occurrences of XPath related
    to Tamino.
   (a) A subset of XPath is used as basis for Tamino's query language
       X-Query with its internal engine
   (b) XPath is used as part of the XSLT processor running as a
       "pass-thru-servlet" outside of the Tamino DB.

   For (a), we did not implement the more sophisticated versions of "axes"
   and some functions, which are only a recommendation but not
   prescribed.
   
   ========================================================================
   Addition: concerning X-Query applied to a single document, there are
   two axes missing in our XPath implementation, also some string-based
   functions. Full XPath support for X-Query will be an architectural item
   only for the "Cornwall" release of Tamino sometime in 2002.
  ========================================================================

[snip]

     ====================================================================

     Q4) Our intended application requires sub-second to single digit
         second responses on XSLT rendering operations from source XML 
         documents that are multi-tens of megabytes in source form (with
         expected output documents in the 10-50Kbyte range). Is Tamino's
         XSLT rendering performance adequate to this?

     A: At the moment, we are depending on the XSLT engines configured on
        top of Tamino DB. With the XSLT processor inside Tamino (not
        Java-based, but written in C++), we expect a considerable increase
        in rendering speed. The same XSLT engine will then also be used
        in other Software AG products.

    ====================================================================
    Addition: Performance is heavily dependent on the platform. Tamino
    scales up to Linux on IBM S/390, therefore it is difficult to tell
    anything without knowledge of the platform.
    ====================================================================

    Q5) Does the XSLT engine support XSLT rendering of XML->XML
        vice XML->HTML? Are there any plans to support XSL:FO?

    A: Both the current implementation and the implementation under
       development support / will support rendering of
       XML->XML as well as XML->HTML (there is even an HTML
       generation feature inside Tamino DB, for specific purposes).

   ====================================================================
   Addition: The "YES" is also true for the second part of the question.
   ====================================================================

[snip]

  Does Tamino have In place editing vs. document reloading:
     In the case that this phrase should be understood as "modify parts
     (subtrees) of   documents" vs. "write whole document", the answer is
     No. Development for this feature is under way, but the feature
     will not be available before the end of 2001.

     We do have, however, a Java API, which encapsulates these
     operations, such that it appears as if the customer
     would only modify part of the document.

---

I am still following up with them and could be wrong, but it sounds like
Tamino has the scaling problems I noted about 'XML Databases' handling
*documents* rather than *data* - due to be solved late this year.

I also checked out X-Hive (which suffers from the same problems) and
looked at Ozone (which is promising, but way too developmental to use for
production).

-- 
Benjamin Franz

... with proper design, the features come cheaply. This 
approach is arduous, but continues to succeed.

                                     ---Dennis Ritchie


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list