Menu
▾
▴
xpipe-developers — XPipe developers list
You can subscribe to this list here.
| 2002 |
Jan
(31) |
Feb
(20) |
Mar
(5) |
Apr
(3) |
May
|
Jun
(5) |
Jul
(33) |
Aug
(10) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
|---|
|
From: Sean M. <sea...@pr...> - 2002-01-09 20:54:14
|
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
|
|
From: David S. <ds...@st...> - 2002-01-09 20:52:33
|
A few more questions as I continue to try and wrap myself around the XPipe way of thinking. To me, the value of a pipeline/component based system is the ability to build a variety of reusable domain specific components in addition to the general purpose components that will undoubtedly be developed. The thing one frequently wonders about these systems is how tight or loose and how static our dynamic the bindings are. XComponents are loosely bound. What is envisioned about how static/dynamic the bindings are? If an XPipe description, like an XComponent description, is an XML file can I create one during execution and then use it? Would I want to given the way the architecture is currently envisioned? Likewise, could I generate an XSLT and an XComponent description for it, bind it to other XComponents at runtime and execute it all? Am I asking reasonable questions, or just being crazy as usual? David David Starr 18 Winthrop Terrace Wayland, MA 01778 (508) 358-2975 da...@st... |
|
From: David S. <ds...@st...> - 2002-01-09 20:34:22
|
> An XML-RPC invoking XComponent is high on the list. I'll see if I can get > to is soon. > > It is a good test of the XComponent model and a very useful XComponent > to boot. 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. 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. 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. 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. David |
|
From: Sean M. <sea...@pr...> - 2002-01-09 19:55:07
|
My issue is that I don't do Java -:) I am learning python, so... but could I >not write stand alone applications/Xcomponents in other languages? Yes. > > Using <Code Type = "Exec"> Include the command line necessary to invoke > your > > app. e.g. "java -cp foo.jar net.xpipe.bar" This can be used to involve anything via "shelling" out of the JVM. Very useful for binaries, batchfiles etc. Can also be used for PVM based Python, Omnimark etc. One of the XComponents I will be putting up over the weekend is the time honoured "tr" command from Unix turned into an XComponent. It is invoked using the "shell escape" mechanism Type = "Exec" provides. >How does XML-RPC fit into the picture? In a nutshell _ I'd like to get on >and write XML components and send 'em over the wire, or locally and not >worry about the language specific issues. An XML-RPC invoking XComponent is high on the list. I'll see if I can get to is soon. It is a good test of the XComponent model and a very useful XComponent to boot. >I think this comes down to the issue of "gateways" - and simple XML based >gateways between language environments is where something like an (http >based?) XML exchange makes sense? I'd like to make a bridge to another >SourceForge project: SIMPL I was not aware of SIMPL until now. Interesting. >Does it make sense for XMKPipe to be a kind of wrapper around SIMPL >environements? I'll need to read more about SIMPL to answer that one. regards (and welcome), Sean |
|
From: David B. <dav...@op...> - 2002-01-09 19:33:21
|
I read (most) of the documentation / site stuff yesterday, and like the approach having spent much of my time lurking / coding around Jabber / XML-RPC and looking at component issues... So I am in. My issue is that I don't do Java -:) I am learning python, so... but could I not write stand alone applications/Xcomponents in other languages? > Using <Code Type = "Exec"> Include the command line necessary to invoke your > app. e.g. "java -cp foo.jar net.xpipe.bar" How does XML-RPC fit into the picture? In a nutshell _ I'd like to get on and write XML components and send 'em over the wire, or locally and not worry about the language specific issues. I think this comes down to the issue of "gateways" - and simple XML based gateways between language environments is where something like an (http based?) XML exchange makes sense? I'd like to make a bridge to another SourceForge project: SIMPL Does it make sense for XMKPipe to be a kind of wrapper around SIMPL environements? David |
|
From: Derek H. <der...@pr...> - 2002-01-08 16:33:53
|
Hi All,
I have created a cgi script that dynamicaly generates the any
documentation on python
modules for us (Uses the pydoc module ). Anybody who is interested can see
it working on sourceforge.net.
Pyxie2 Docs - http://xpipe.sourceforge.net/cgi-bin/doc.py?module=Pyxie2
XComponentObjectModel -
http://xpipe.sourceforge.net/cgi-bin/doc.py?module=XComponentObjectModel
It's still a work in progress so please bare with me.
Mail me with any ideas/comments.
Derek
---
Every snowflake in an avalanche pleads not guilty.
=============================
Derek Higgins
derek.higgins at propylon.com
=============================
|
|
From: Sean M. <sea...@pr...> - 2002-01-05 18:31:08
|
All, I am pleased to announce that XPipe 0.2 is now available on Sourceforge (http://xpipe.sourceforge.net) The CVS tree will appear Monday, for now you can get the source at http://xpipe.sourceforge.net/XPipe0.2.zip and http://xpipe.sourceforge.net/XPipe0.2.tar.gz This release purposely does not do very much:-). The intent is to solicit help and comments from XML developers in refining the fundamental XComponent model. Roadmap information is available at http://xpipe.sourceforge.net/Articles/Documentation/fog0000000039.html. A RelaxNG schema for XComponents is available at: http://xpipe.sourceforge.net/XComponent.rng Some documentation on the structure is available at : http://xpipe.sourceforge.net/XComponent.html XPipe includes a new incarnation of the Pyxie XML tree processing library suitable for use with Jython (http://www.jython.org). Anybody interested in helping out, please join the XPipe developers list http://lists.sourceforge.net/lists/listinfo/xpipe-developers/. and visit the wish list. Further announcements will be on the XPipe developers list only. Normal XML-DEV service will now resume... Sean |
1 message has been excluded from this view by a project administrator.
