RE: [Xpipe-developers] Hi...

[Sean M. <sea...@pr...>]

At 15:39 09/01/2002 -0500, David Starr wrote:
>Once there is some sort of an executive it seems to me that it would be
>interesting to package the XComponent modules that index and document
>XCcomponents as XComponents themselves.

Agreed.

Its easy to make your head spin with the bootstrapping possibilities
bits of XPipe - such as its documentation generators - present.

I'm fighting the urge to turn the XComponent RelaxNG validation
into a 4-stage XPipe at the moment! All in good time...

For now, I'm taking the approach that some of the
XPipe code I'm working on right now may well be re-worked under
the XPipe XComponent/XPipe infrastructure once we have a running
system in place.


>On another note, I have some components that I have used on other pipeline
>projects that I would be happy to package as XComponents.  The first would
>likely be one that can perform arbitrary queries against arbitrary JDBC
>sources.

Great. I have a draft generic JDBC -> XML XComponent written in Java. It would
be good to compare them.

>I'm not sure that I fully understand your vision for who XPipes will be
>combined.  So before I assume that the philosophy is similar to ones I've
>worked with in the past, let me explain the component, then perhaps you can
>give me some guidance as to how it might work with the XPipe system.  The
>following Javadoc excerpt explains the filter.
>
>JDBCQueryFilter is a SAX pipeline filter that takes occurrences of
><SQLQuery> ... </SQLQuery> in XML documents and executes query defined by
>these elements. The <SQLQuery> structure is replaced by a &<QueryResults>>
>structure that contains the results of the query. The SQLQuery element
>requires that four elements be specified.
>
>Driver - The class name of the JDBC driver to use.
>DatabaseURL - A URL specifying where to find the database.
>Login - The login used to authenticate with the database.
>Password - The password associated with the given Login. The results are
>replaced with a structure that looks like <QueryResults> <Row> <Cell
>column="name of column" value="value of column"/> <Cell column="name of
>column" value="value of column"/> ... </Row> <Row> <Cell column="name of
>column" value="value of column"/> <Cell column="name of column" value="value
>of column"/> ... </Row> ... </QueryResults> Anything not contained in the
><QueryFilter> structure is passed through the filter untouched.
>
>It's fairly trivial to change this from an SAX filter to an XCOmponent.  But
>does it fit the XPipe paradigm.

Absolutely.

>   Would it be more useful if the query was
>supplied as a parameter.  If so, how would one specify where to place it in
>the source document.

Both embedded queries and parameter based queries are useful.

The draft JDBC XComponent I've done is of the latter form.

In the XComponent Paramerers section is something like:

<Parameters>
         <Parameter Name = "DataSource"/>
         <Parameter Name = "Query"/>
</Parameters>


In the relevant part of an XPipe invoking this XComponent there is 
something like:
         <Parameters>
                 <Parameter Name = "DataSource">MyOracle</Parameter>
                 <Parameter Name = "Query">select * from Employees</Parameter>
         </Parameters>

This XComponent is a data producer - it does expect anything to be in its 
input file, so although
the XPipe executive supplies it with InputFile, OutputFile, 
LogFile,<Params> - just like any other
XComponent - the contents of InputFile are actually irrelevant for data 
producing XComponents.

I'm hoping to have a database-centric example as part of XPipe 0.6 later 
this month.
It is particularly relevant to the Scatter/Gather approach to scaleable 
XSLT processing
(http://xpipe.sourceforge.net/Articles/Documentation/fog0000000033.html) 
that I plan
to have written by then.

David, please send over your code and I'll create an XComponent from it. It 
will be a good
test of the XComponent model which still needs work to deal with real live 
code.

Sean