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: Aidan M. H. <ah...@gm...> - 2002-04-03 18:14:56
|
Hi all. Zombified, heavily jet lagged after returning from giving a talk at JavaOne I found myself searching Google for "TupleSpaces". Up popped an XML-Dev posting by Sean McGrath, which lead me to this project. Take a look at this: http://www.sun.com/jini/news/Jini-procoma.pdf or start at http://www.sun.com/jini/ and I think you will understand my interest in this project. Chameleon/XML = XML/XSLT pipeling, Java, Jini, TupleSpaces. Basically we seem to have been thinking on the same lines but on different tracks so to say. Is this interesting to you and your project? Not sure how much time I have to contribute or even if I would be much help, but having taken a similar system from concept to production in a B-I-G Financial Services institution maybe an exchange of notes might be interesting to both parties. Aidan Mark Humphreys. ps. Since Procoma are selling their product commercially, we have taken contracts out on all you guys. pps. Only joking. |
|
From: David S. <ds...@st...> - 2002-03-02 14:15:30
|
Yes, I see that now. I hadn't known that this was one of the changed in 0.6. I was using some test XComponents that I had written prior to 0.6 and the Java code, which didn't change in 0.6. I guess I'll also need to change the Java code to conform. David > -----Original Message----- > From: Sean McGrath [mailto:sea...@pr...] > Sent: Saturday, March 02, 2002 7:29 AM > To: David Starr; xpi...@li... > Subject: Re: [Xpipe-developers] Current .xco files don't validate with > xcomponent.rng and xcomponent.dtd > > > David, > > I had though I had fixed all the case issues in the 0.6 release. > All tags > now in > lowercase in instances + schemas. > > I've looked at a few XCO files from my 0.6 release here and they are all > in lowercase. What particular files are you seeing uppercase tagging > in? > > Sean > > > At 21:36 01/03/2002 -0500, David Starr wrote: > >Hey Sean (and others), > > > > I've been working on adding pre- and post-condition validation > > code to the > >Java version of XComponent. Since I don't have any non-trivial > .rng files > >for testing, I tried to validate existing XComponents against > >xcomponent.rng. The initial problem is <XComponent> tag in the > XComponents > >when the .rng spec calls for an all lower case <xcomponent> tag. > The .rng > >file disagrees with both the existing .xco files and existing java and > >python code with regard to the capitalization of every tag I looked at. > >xcomponent.dtd seems to have the same issues. > > > > It looks like we need to either change the .rng file or > the existing > >components and existing code. I have no particular preference > about which > >way to go. Please advise. > > > >David > > > > > >_______________________________________________ > >Xpipe-developers mailing list > >Xpi...@li... > >https://lists.sourceforge.net/lists/listinfo/xpipe-developers > > http://www.propylon.com > |
|
From: Sean M. <sea...@pr...> - 2002-03-02 12:29:08
|
David, I had though I had fixed all the case issues in the 0.6 release. All tags now in lowercase in instances + schemas. I've looked at a few XCO files from my 0.6 release here and they are all in lowercase. What particular files are you seeing uppercase tagging in? Sean At 21:36 01/03/2002 -0500, David Starr wrote: >Hey Sean (and others), > > I've been working on adding pre- and post-condition validation > code to the >Java version of XComponent. Since I don't have any non-trivial .rng files >for testing, I tried to validate existing XComponents against >xcomponent.rng. The initial problem is <XComponent> tag in the XComponents >when the .rng spec calls for an all lower case <xcomponent> tag. The .rng >file disagrees with both the existing .xco files and existing java and >python code with regard to the capitalization of every tag I looked at. >xcomponent.dtd seems to have the same issues. > > It looks like we need to either change the .rng file or the existing >components and existing code. I have no particular preference about which >way to go. Please advise. > >David > > >_______________________________________________ >Xpipe-developers mailing list >Xpi...@li... >https://lists.sourceforge.net/lists/listinfo/xpipe-developers http://www.propylon.com |
|
From: David S. <ds...@st...> - 2002-03-02 02:37:40
|
Hey Sean (and others), I've been working on adding pre- and post-condition validation code to the Java version of XComponent. Since I don't have any non-trivial .rng files for testing, I tried to validate existing XComponents against xcomponent.rng. The initial problem is <XComponent> tag in the XComponents when the .rng spec calls for an all lower case <xcomponent> tag. The .rng file disagrees with both the existing .xco files and existing java and python code with regard to the capitalization of every tag I looked at. xcomponent.dtd seems to have the same issues. It looks like we need to either change the .rng file or the existing components and existing code. I have no particular preference about which way to go. Please advise. David |
|
From: Michael B. <Mic...@Al...> - 2002-03-01 19:12:05
|
Cool! This proposal looks pretty good to me, although there are some fuzzy areas. One thing I wasn't clear on is if I can parameterize all of the inputs and outputs. It uses URIs for these and the only thing that seems to be passed in from the application context is the target. (Or at least that's what the note says, though in looking at the examples, it didn't seem evident to me that the target was really an external parameter.) I'd like to have something like this where the pipeline def is a model that does not specify hard-coded paths (except perhaps for temporary intermediate files), and lets me specify the concrete inputs and target at runtime, not just the target. It doesn't seem to permit that in its current formulation, unless I've misread it. -----Original Message----- From: Sean McGrath To: Michael Brennan; xpi...@li... Sent: 3/1/02 2:56 AM Subject: Re: [Xpipe-developers] FW: [xml-dev] Check out the pipeline submission Michael, The company I work for, Propylon, are involved with this W3C submission and I hope to be able to get involved in whatever W3C activities come from it. http://www.w3.org/Submission/2002/01/Comment Sean |
|
From: Sean M. <sea...@pr...> - 2002-03-01 11:25:48
|
Michael, The company I work for, Propylon, are involved with this W3C submission and I hope to be able to get involved in whatever W3C activities come from it. http://www.w3.org/Submission/2002/01/Comment Sean At 15:48 28/02/2002 -0800, Michael Brennan wrote: >In case anyone on this list hasn't seen this, I thought I'd forward it. It >seems relevant. > >-----Original Message----- >From: Tim Bray [mailto:tb...@te...] >Sent: Thursday, February 28, 2002 3:34 PM >To: xm...@li... >Subject: [xml-dev] Check out the pipeline submission > > >http://www.w3.org/TR/xml-pipeline/ > >I hear a heavy echo of OS360 JCL... //step1.sysin dd etc.... > > -Tim > > >_______________________________________________ >Xpipe-developers mailing list >Xpi...@li... >https://lists.sourceforge.net/lists/listinfo/xpipe-developers http://www.propylon.com |
|
From: Michael B. <Mic...@Al...> - 2002-02-28 23:50:45
|
In case anyone on this list hasn't seen this, I thought I'd forward it. It seems relevant. -----Original Message----- From: Tim Bray [mailto:tb...@te...] Sent: Thursday, February 28, 2002 3:34 PM To: xm...@li... Subject: [xml-dev] Check out the pipeline submission http://www.w3.org/TR/xml-pipeline/ I hear a heavy echo of OS360 JCL... //step1.sysin dd etc.... -Tim |
|
From: Roger L. C. <cos...@mi...> - 2002-02-24 19:55:55
|
Last week Sean shared code for invoking ExecuteXPipe from a Java
program. His code was for a Unix platform. I have modified (and
extended) it for the windows platform.
ExecuteXPipe.java
/*
* The program is provided "as is" without any warranty express or
* implied, including the warranty of non-infringement and the implied
* warranties of merchantibility and fitness for a particular purpose.
* The author will not be liable for any damages suffered by
* you as a result of using the Program. In no event will the
* author be liable for any special, indirect or consequential damages
* or lost profits even if the Copyright owner has been advised of the
* possibility of their occurrence.
*/
import org.python.util.PythonInterpreter;
import org.python.core.*;
public class ExecuteXPipe {
public static String root = "c:\\\\new-xml-course";
public static void main(String []args)
throws PyException
{
if (args.length != 4) {
System.out.println("Usage: java ExecuteXPipe <dir> <in>
<out> <log>");
return;
}
System.out.print(". ");
PythonInterpreter interp = new PythonInterpreter();
System.out.print(". ");
interp.exec ("import sys");
System.out.print(". ");
interp.exec ("sys.path.extend (['" + root + "\\\\xpipe','" +
root + "\\\\xpipe\\src\\\\jython\\\\src','" + root +
"\\\\jython\\\\Lib','" + root +
"\\\\xpipe\\src\\\\jython\\\\src\\\\net\\\\xpipe'])");
System.out.print(". ");
interp.exec ("from ExecuteXPipe import executeXPipe");
System.out.println(".");
interp.exec ("executeXPipe ('" + args[0] + "','" + args[1] +
"','" + args[2] + "','" + args[3] + "')");
}
}
Here's an example of how to invoke this program:
java ExecuteXPipe testdir in.xml out.xml log.xml
/Roger
|
|
From: Sean M. <sea...@pr...> - 2002-02-23 12:11:02
|
Michael, Swan sounds like and interesting project. As for Ant dependancies in XPipe - Ant will purely be used as a build tool for the XPipe source. Welcome to the XPipe developers list. Sean At 16:12 22/02/2002 -0800, Michael Brennan wrote: >Greetings. I've just subscribed to this list after looking over the >presentation (after seeing it mentioned on xml-dev). > > >From the presentation: > > Evangelize the idea that DTD validated XML 1.0 > is just Well Formed XML that has been through a pipe consisting of: > A transclusion component (entity expansion) > A macro pre-processor (conditional marked sections) > An attribute decorator (implied/fixed attributes) > A grammar checker > ... > >Nice. You just sold me. > >I'm trying to devote some of my spare time to a little open source project I >have going [1]. Nothing released yet, but the basic editor functionality is >almost done (though it was much more work than I anticipated). One thing I'm >hoping to get to is a pipeline-based processing framework that would permit >users to write lightweight components that can hook in and do processing on >appropriate documents. It is my intention to provide a layered approach to >validation, "attribute decoration", transformation, etc. I've looked at >GNUJAXP pipeline[2] package for inspiration, as well as (recently) the >SAX::Machine [3] package available for Perl. But XPipe looks like it may >fit, here. > >I'll have to look into this more over the weekend. I see someone has started >to work on an editor for Netbeans. I'd love to reuse what I can, but >unfortunately Eclipse does things differently and even uses its own >completely different UI framework (no AWT or Swing). I've also seen some >mention of Ant. Eclipse supports Ant, but also has a notion of more >granular, lightweight processing kicking in every time a resource in the >workspace is changed. I'm leveraging this, at present, so it would be great >if XPipe did not have an explicit dependency on Ant. Is this currently the >case? > >Thanks. > >[1] http://swan.sourceforge.net/ >[2] >http://www.gnu.org/software/classpathx/jaxp/apidoc/gnu/xml/pipeline/package- >summary.html >[3] http://www.xml.com/pub/a/2002/02/13/sax-machines.html > > >_______________________________________________ >Xpipe-developers mailing list >Xpi...@li... >https://lists.sourceforge.net/lists/listinfo/xpipe-developers http://www.propylon.com |
|
From: Michael B. <Mic...@Al...> - 2002-02-23 00:14:45
|
Greetings. I've just subscribed to this list after looking over the presentation (after seeing it mentioned on xml-dev). From the presentation: Evangelize the idea that DTD validated XML 1.0 is just Well Formed XML that has been through a pipe consisting of: A transclusion component (entity expansion) A macro pre-processor (conditional marked sections) An attribute decorator (implied/fixed attributes) A grammar checker ... Nice. You just sold me. I'm trying to devote some of my spare time to a little open source project I have going [1]. Nothing released yet, but the basic editor functionality is almost done (though it was much more work than I anticipated). One thing I'm hoping to get to is a pipeline-based processing framework that would permit users to write lightweight components that can hook in and do processing on appropriate documents. It is my intention to provide a layered approach to validation, "attribute decoration", transformation, etc. I've looked at GNUJAXP pipeline[2] package for inspiration, as well as (recently) the SAX::Machine [3] package available for Perl. But XPipe looks like it may fit, here. I'll have to look into this more over the weekend. I see someone has started to work on an editor for Netbeans. I'd love to reuse what I can, but unfortunately Eclipse does things differently and even uses its own completely different UI framework (no AWT or Swing). I've also seen some mention of Ant. Eclipse supports Ant, but also has a notion of more granular, lightweight processing kicking in every time a resource in the workspace is changed. I'm leveraging this, at present, so it would be great if XPipe did not have an explicit dependency on Ant. Is this currently the case? Thanks. [1] http://swan.sourceforge.net/ [2] http://www.gnu.org/software/classpathx/jaxp/apidoc/gnu/xml/pipeline/package- summary.html [3] http://www.xml.com/pub/a/2002/02/13/sax-machines.html |
|
From: Allan D. <ad...@in...> - 2002-02-22 18:18:22
|
On Thursday 2002-02-21 at 08:40:51(+0000) Sean McGrath wrote: > I recently gave a talk about the XPipe appoach to XML processing > at the XML SIG of New York. > > The slides from the talk are available on http://xpipe.sourceforge.net at > http://xpipe.sourceforge.net/BinaryStuff/xpipeny.ppt > Good stuff, thanks for sharing... It strikes me that XPipe and REST are meant for each other. Machine-to-machine REST is really about transformations on XML documents. Allan -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Allan Doyle http://www.intl-interfaces.com ad...@in... |
|
From: Sean M. <sea...@pr...> - 2002-02-21 08:41:29
|
I recently gave a talk about the XPipe appoach to XML processing at the XML SIG of New York. The slides from the talk are available on http://xpipe.sourceforge.net at http://xpipe.sourceforge.net/BinaryStuff/xpipeny.ppt Sean |
|
From: Sean M. <sea...@pr...> - 2002-02-20 14:31:24
|
(I'm cc'ing the developers list as I think Rogers questions are relevant
there - especially how to invoke the current stuff from within a Java=20
program.).
At 08:49 20/02/2002 -0500, Roger L. Costello wrote:
>This is a great technology! Thanks Sean et al.
>
>Still more questions:
>
>1. The xrigs directory is empty.
Yes :-(
> When will this get implemented? I'd
>like to start using this technology (and marketing it to my customers),
>but without XRig I don't see it as being very useful (need branches in
>the pipe for error handling).
Yes. I'm going to get to it as soon as possible but I cannot at this
stage say when it will appear. I'm hoping to make big strides
before end of March but cannot be more specific than that
at this point.
>2. Sean, I looked at your briefing at XML SIG. It seems to me that
>xcomponents are not consistent with xpipe and xrig. Consider these
>slides (28, 29, 30):
>
>Major Functional Elements - XComponents
>
>XComponents described in XML form. An XComponent consists of:
> ...
> - Code (Java / Jython / XSLT / Exec)
>
>Major Functional Elements =AD XPipes
>
>Described in XML:
> ...
> - References to XComponents (URIs) which are resolved when the
> XPipe is installed/executed
>
>Major Functional Elements =AD XRigs
>
>Described in XML:
>
> ...
> - References to XPipes (URIs) which are resolved when the
> XRig is installed/executed
>
>Notice that XPipes and XRigs provide "references" to the lower level
>component, whereas XComponents "inline" code. To be consistent,
>shouldn't XComponents "reference" code? (Then, anything could be an
>XComponent. A web service could be an XComponent! Then this technology
>can be used at both a micro and macro level.)
XComponents can contain code so as to make it possible to produce
self-contained XComponents. This is particularly useful for XSLT
components.
The <code> element is missing a href attribute which would allow external
references. This will be fixed in the next release.
>3. I see how to kick off the XPipe engine from a command line. How do I
>do it from a Java program?
An example of how to do this will be in the next release. In the meantime,=
=20
this works:-
import org.python.util.PythonInterpreter;
import org.python.core.*;
public class ExecuteXPipe {
public static void main(String []args)
throws PyException
{
PythonInterpreter interp =3D
new PythonInterpreter();
interp.exec ("import sys");
interp.exec ("sys.path.extend=20
(['d:/xpipe','d:/xpipe/undercvs/xpipe/src/jython/src','d:/xpipe/jython/Lib']=
)");
interp.exec ("from ExecuteXPipe import executeXPipe");
interp.exec ("executeXPipe ('/foo','in.xml','out.xml','log.xml')");
}
}
You will need to change the line that is extending the PYTHONPATH so that=20
it includes whatever directories you need.
Then just change the last line to point to wherever you have your XPipe=20
installed, your input/output XML and log file and
you are all set.
>4. Sean, perhaps you could notify this list when/where you will be
>giving a presentation on this technology? I would have liked to attend
>your XML SIG talk.
Sure. Will do.
>5. I am eager to see the format of how you express <pre> and
><post>-conditions.
High on the list :-)
regards,
Sean
|
|
From: Sean M. <sea...@pr...> - 2002-02-06 12:52:06
|
David, Excellent. Thanks. I'd appreciate any suggestions as to how best to package the jythonc compiled stuff and how best to integrate into building this stuff into Ant. Sean At 16:59 05/02/2002 -0500, David Starr wrote: >Sean, > > I was able to get this sample code to work with a few minor > mods. I had >problems executing the code you supplied in the interpreter, specifically, >it did not like me referencing the fully qualified path names of classes I >had imported. I fixed this (and needed to import ContentHandler as well. I >have some problems with jythonc invoking javac on my machine so I compiled >to java and compiled the java by hand. You shouldn't run in to this problem >but figured I'd share all the variables. I'm running Jython 2.1 on Windows. >Ouput looks like this. > >C:\current\xpipe\jpywork>java SAXEventDispatcher ><xml.sax.drivers2.drv_xmlproc.XmlprocDriver instance at 7134136> > >good luck! > > >#------------------------------------------- >from xml.sax import saxutils >from xml.sax import make_parser >from xml.sax import ContentHandler > ># Help jythonc to see modules imported at run-time using import hookery >def dummy_jythonc(): > import xml.sax.drivers2.drv_xmlproc > >class SAXEventDispatcher (ContentHandler): > pass > >parser = make_parser(["xml.sax.drivers2.drv_xmlproc"]) >print parser >#------------------------------- > > > > -----Original Message----- > > From: xpi...@li... > > [mailto:xpi...@li...]On Behalf Of Sean > > McGrath > > Sent: Tuesday, February 05, 2002 2:23 PM > > To: xpi...@li... > > Subject: [Xpipe-developers] Help needed tracking down jython compiler > > problem > > > > > > Hi. > > > > In the great cunning plan, all the programs that make up XPipe's > > set of command > > line utilities will be distributed as Java class files combined > > into a Jar > > file. > > Jython source can be compiled to java source and thence to .class format > > using the wonderful jythonc utility that ships with jython > > (http://www.jython.org/docs/jythonc.html). > > > > Now here is the problem. I am having trouble getting even small > > Jython programs > > that use the XML support in Jython, to work in their compiled form. > > > > The problem is to do with dynamic importing of modules - the > > compiler cannot > > see these automatically so needs to be told of their existence. > > > > For example, here is a suggestion from Finn Bock that helps: > > > > def dummy_jythonc(): > > import xml.sax.drivers2.drv_xmlproc > > > > Putting this into a program has the effect of making the > > xml.sax.drivers2.drv_xmlproc > > module visibile to jythonc. Without this addition, my program claims "no > > XML parsers found". > > > > I have added this to my program and now I get further on but still get > > run-time errors - this time with > > an xmlval module. > > > > Here is my test case program which is only a handful of lines long: > > > > # ----------------- > > from xml.sax import saxutils > > from xml.sax import makeparser > > > > # Help jythonc to see modules imported at run-time using import hookery > > def dummy_jythonc(): > > import xml.sax.drivers2.drv_xmlproc > > > > class SAXEventDispatcher (sax.ContentHandler): > > pass > > > > parser = sax.make_parser(["xml.sax.drivers2.drv_xmlproc"]) > > print parser > > # ----------------- > > > > I'd appreciate help tracking down what it is about this program > > that continues > > to cause jythonc grief. > > > > regards, > > Sean > > > > > > http://www.propylon.com > > > > > > > > _______________________________________________ > > Xpipe-developers mailing list > > Xpi...@li... > > https://lists.sourceforge.net/lists/listinfo/xpipe-developers |
|
From: David S. <ds...@st...> - 2002-02-05 22:00:15
|
Sean,
I was able to get this sample code to work with a few minor mods. I had
problems executing the code you supplied in the interpreter, specifically,
it did not like me referencing the fully qualified path names of classes I
had imported. I fixed this (and needed to import ContentHandler as well. I
have some problems with jythonc invoking javac on my machine so I compiled
to java and compiled the java by hand. You shouldn't run in to this problem
but figured I'd share all the variables. I'm running Jython 2.1 on Windows.
Ouput looks like this.
C:\current\xpipe\jpywork>java SAXEventDispatcher
<xml.sax.drivers2.drv_xmlproc.XmlprocDriver instance at 7134136>
good luck!
#-------------------------------------------
from xml.sax import saxutils
from xml.sax import make_parser
from xml.sax import ContentHandler
# Help jythonc to see modules imported at run-time using import hookery
def dummy_jythonc():
import xml.sax.drivers2.drv_xmlproc
class SAXEventDispatcher (ContentHandler):
pass
parser = make_parser(["xml.sax.drivers2.drv_xmlproc"])
print parser
#-------------------------------
> -----Original Message-----
> From: xpi...@li...
> [mailto:xpi...@li...]On Behalf Of Sean
> McGrath
> Sent: Tuesday, February 05, 2002 2:23 PM
> To: xpi...@li...
> Subject: [Xpipe-developers] Help needed tracking down jython compiler
> problem
>
>
> Hi.
>
> In the great cunning plan, all the programs that make up XPipe's
> set of command
> line utilities will be distributed as Java class files combined
> into a Jar
> file.
> Jython source can be compiled to java source and thence to .class format
> using the wonderful jythonc utility that ships with jython
> (http://www.jython.org/docs/jythonc.html).
>
> Now here is the problem. I am having trouble getting even small
> Jython programs
> that use the XML support in Jython, to work in their compiled form.
>
> The problem is to do with dynamic importing of modules - the
> compiler cannot
> see these automatically so needs to be told of their existence.
>
> For example, here is a suggestion from Finn Bock that helps:
>
> def dummy_jythonc():
> import xml.sax.drivers2.drv_xmlproc
>
> Putting this into a program has the effect of making the
> xml.sax.drivers2.drv_xmlproc
> module visibile to jythonc. Without this addition, my program claims "no
> XML parsers found".
>
> I have added this to my program and now I get further on but still get
> run-time errors - this time with
> an xmlval module.
>
> Here is my test case program which is only a handful of lines long:
>
> # -----------------
> from xml.sax import saxutils
> from xml.sax import makeparser
>
> # Help jythonc to see modules imported at run-time using import hookery
> def dummy_jythonc():
> import xml.sax.drivers2.drv_xmlproc
>
> class SAXEventDispatcher (sax.ContentHandler):
> pass
>
> parser = sax.make_parser(["xml.sax.drivers2.drv_xmlproc"])
> print parser
> # -----------------
>
> I'd appreciate help tracking down what it is about this program
> that continues
> to cause jythonc grief.
>
> regards,
> Sean
>
>
> http://www.propylon.com
>
>
>
> _______________________________________________
> Xpipe-developers mailing list
> Xpi...@li...
> https://lists.sourceforge.net/lists/listinfo/xpipe-developers
|
|
From: Sean M. <sea...@pr...> - 2002-02-05 19:23:50
|
Hi. In the great cunning plan, all the programs that make up XPipe's set of command line utilities will be distributed as Java class files combined into a Jar file. Jython source can be compiled to java source and thence to .class format using the wonderful jythonc utility that ships with jython (http://www.jython.org/docs/jythonc.html). Now here is the problem. I am having trouble getting even small Jython programs that use the XML support in Jython, to work in their compiled form. The problem is to do with dynamic importing of modules - the compiler cannot see these automatically so needs to be told of their existence. For example, here is a suggestion from Finn Bock that helps: def dummy_jythonc(): import xml.sax.drivers2.drv_xmlproc Putting this into a program has the effect of making the xml.sax.drivers2.drv_xmlproc module visibile to jythonc. Without this addition, my program claims "no XML parsers found". I have added this to my program and now I get further on but still get run-time errors - this time with an xmlval module. Here is my test case program which is only a handful of lines long: # ----------------- from xml.sax import saxutils from xml.sax import makeparser # Help jythonc to see modules imported at run-time using import hookery def dummy_jythonc(): import xml.sax.drivers2.drv_xmlproc class SAXEventDispatcher (sax.ContentHandler): pass parser = sax.make_parser(["xml.sax.drivers2.drv_xmlproc"]) print parser # ----------------- I'd appreciate help tracking down what it is about this program that continues to cause jythonc grief. regards, Sean http://www.propylon.com |
|
From: Sean M. <sea...@pr...> - 2002-02-05 16:31:12
|
At 11:04 05/02/2002 -0500, David Starr wrote: >I just took a look through the 0.6 code (still have to look at the NetBeans >editor component). I see that the XPipe XComponents element no longer has a >ScheduleType which was the bit that I was waiting on the code for to >complete my understanding. So with that missing, I guess I fully understand >XPipes now. Scheduling is back in primordial soup land in my head. I've been reading a lot about emergent behaviour, web services orchestration, XLANG etc. and think some more thinking time is in order before I put forward a proposal for scheduling. Ideas solicited! >Apart from what's in the development plan, there seem to be a number of >things left to take care of in the existing components: > - Parameter passing. > - Testing of pre- and post-conditions. > - Generalizing unit testing so that it extends to XPipes. > >Is there a plan for these? I know that my Java implementations don't >currently fit the 'unpack an XComponent' model. If it's desired to have >these implemented in Java, I could presumably rework a version in Java that >acts on unpacked components (although it's my personal preference to try and >avoid unpacking) and add some of the items mentioned above. These are on my list for this weekend. A side-effect of the parameter passing work will be that xc5 - the first "Exec" component will become functional. I'd really appreciate help getting the Ant build (build.xml) into shape David. If you get some time could you take a look at it? Sean |
|
From: David S. <ds...@st...> - 2002-02-05 16:04:56
|
I just took a look through the 0.6 code (still have to look at the NetBeans
editor component). I see that the XPipe XComponents element no longer has a
ScheduleType which was the bit that I was waiting on the code for to
complete my understanding. So with that missing, I guess I fully understand
XPipes now.
Apart from what's in the development plan, there seem to be a number of
things left to take care of in the existing components:
- Parameter passing.
- Testing of pre- and post-conditions.
- Generalizing unit testing so that it extends to XPipes.
Is there a plan for these? I know that my Java implementations don't
currently fit the 'unpack an XComponent' model. If it's desired to have
these implemented in Java, I could presumably rework a version in Java that
acts on unpacked components (although it's my personal preference to try and
avoid unpacking) and add some of the items mentioned above. I could also
give a shot in Jython, although I'm pretty inexperienced there. I can also
wait, if these are already in the works.
David
|
|
From: Sean M. <sea...@pr...> - 2002-02-05 11:22:47
|
At 10:09 04/02/2002 -0500, DuCharme, Bob (LNG) wrote: >Just to clarify: this means the people who will be create actual XComponents >and XPipes, as opposed to the people working on the software that makes it >easier to create XComponents and XPipes, right? Right. Sean |
|
From: DuCharme, B. (LNG) <bob...@le...> - 2002-02-04 15:10:16
|
Just to clarify: this means the people who will be create actual XComponents and XPipes, as opposed to the people working on the software that makes it easier to create XComponents and XPipes, right? Great mascot, by the way--I like the part about how they "leave an invisible scent on the trails they use in order to find their way home" and how they make "a bed of fertilizer on which a special type of fungus is grown." Bob DuCharme www.snee.com/bob <bob@ snee.com> "The elements be kind to thee, and make thy spirits all of comfort!" Anthony and Cleopatra, III ii -----Original Message----- From: Sean McGrath [mailto:sea...@pr...] Sent: Sunday, February 03, 2002 2:56 PM To: xpi...@li... Subject: [Xpipe-developers] XPipe users list A list has been created for for XPipe users. This list will be for end-users and not get into the nitty gritty of software development issues - which will be the preserve of this list. http://lists.sourceforge.net/lists/listinfo/xpipe-users/ Sean _______________________________________________ Xpipe-developers mailing list Xpi...@li... https://lists.sourceforge.net/lists/listinfo/xpipe-developers |
|
From: Sean M. <sea...@pr...> - 2002-02-03 19:56:27
|
A list has been created for for XPipe users. This list will be for end-users and not get into the nitty gritty of software development issues - which will be the preserve of this list. http://lists.sourceforge.net/lists/listinfo/xpipe-users/ Sean |
|
From: Sean M. <sea...@pr...> - 2002-02-03 19:53:45
|
All, Version 6 released. Sourceforge playing up on me. Best to follow the link on xpipe.sourceforge.net. CVS not updated yet. Lots of changes, reorgs and new stuff. In particular sample XPipe and Executive. Feedback welcome. First part of the updated README below. I'm off to visit with my family. regards, Sean ===== $Id$ Welcome to XPipe Source Version 0.6 - 03 Feb 2002 Prerequisites: Java 1.2 or higher Jython 2.1 or higher (http://www.jython.org) A Relax NG validator such as (http://www.thaiopensource.com/relaxng/jing.html) or Sun's MultiSchema Validator (http://www.sun.com/software/xml/developers/multischema/) An implementation of JAXP 1.1 (http://java.sun.com/xml/jaxp/index.html) JDOM (http://www.jdom.org) (Only required if you are doing development) Installation Instructions: Install Jython etc as per the instructions that come with those packages Unpack the Xpipe0.6.tar/zip into some suitable directory (\xpipe in what follows) Set the environment variable XPIPE_HOME to the installtion directory Ensure that the xpipe directory is on the Jython module search path. To do this make an entry such as the following in the registry file that ships with Jython # Seans Python Path for XPipe work python.path = d:\\xpipe;d:\\xpipe\\jython\\Lib Ensure that the necessary jaxp1.1 modules are on your classpath e.g xerces.jar xalan.jar (Note that there is no longer a jaxp.jar). With this release you can: Install XComponents Execute XComponents Unit Test XComponents Install XPipes Execute XPipes Unit Test XPipes Details of how to test this release below. First, the main changes: Version 0.6 Changes ------------------- Major code re-org affecting every line of code in the system. Done to conform to Java best practices re naming conventions, packages etc. Ant based build Instigated XPipe schema XPipe Object Model XPipe Catalog Generator XPipe Datasheet Generator XPipe Installer XPipe Unit Tester EPipe Executor DTDs for XPipe and XComponent models. Note that RelaxNG version is normative. Made ExecuteXComponent.py useful as standalone program - will accept command line arguments for what component, input file, output file, and log file to use. Fixes to Installation Instructions Java XComponent Object Model by David Starr checked in. New component from David Starr: xc4.xco - generate XComponent HTML documentation using XSLT NetBeans based XComponent Editor from David Shalamberidze checked in. Testing this Release: (The tests for the Version 0.4 release still apply. Note there are some new XComponents to play with.) The focus of this release is the the XPipe model. It is now possible to: Install XPipes Execute XPipes Unit Test XPipes A sample XPipe is provided in the xpipes directory (xp0.xpi). It is a null transformation XPipe. Its purpose in life is to replicate an input XML file on its output. This might not sounds very useful but it is as it is the first step towards really useful transformations. xp0.xpi takes the scenic route to a null transformation - it routes files through three XComponents: a Jython based null transformtion (xc1.xco) an XSLT based null transformation (xc2.xco) and a Java based null transformation component (xc3.xco) Here's how to test it. Set XPIPE_HOME to whereevery you have installed XPipe Install the xp0.xpi pipe into some suitable directory (testdir here): jython InstallXPipe.py xp0.xpi testdir You will see lots of messages as the pipe is installed. <testdir> should have a top level structure like this: 03/02/2002 18:45 <DIR> . 03/02/2002 18:45 <DIR> .. 03/02/2002 18:45 <DIR> failed 03/02/2002 18:45 <DIR> incoming 03/02/2002 18:45 <DIR> outgoing 03/02/2002 18:45 <DIR> test0000 03/02/2002 18:45 <DIR> xcomponent0000 03/02/2002 18:45 <DIR> xcomponent0001 03/02/2002 18:45 <DIR> xcomponent0002 03/02/2002 18:45 47 XPipe.html Each of the three components that make up this pipe have been laid out in subdirectories - the one unit test for this xpipe - test000 is also installed. Create a little XML file - in.xml like this: <foo> Hello world </foo> Execute the pipe on this file like this: jython ExecuteXPipe.py testdir in.xml out.xml log.log When this completes you should have a file out.xml that looks like this: <?xml version="1.0" encoding="UTF-8"?> <foo> Hello world </foo> and a log file looking something like this: path = '/test' Input File = 'in.xml' Output File = 'out.xml' Log File = 'log.log' Executing XComponent 0: (\test\xcomponent0000\incoming\in.xml,\test\xcomponent0001\incoming\in.xml,/test\Log0000.log) Executing XComponent 1: (\test\xcomponent0001\incoming\in.xml,\test\xcomponent0002\incoming\in.xml,/test\Log0001.log) Executing XComponent 2: (\test\xcomponent0002\incoming\in.xml,out.xml,/test\Log0002.log) The file in.xml have been daisy chained through a Java component, an XSLT component and a Jython component. Now all we need are some useful XComponents:-) Notes: All the "commands" in XPipe will be available in Jar form as soon as I sort out a wee problem with the jython compiler and SAX. xc5.xco - shows sample syntax for Exec Xcomponents - This is for discussion only and is not implemented yet http://www.propylon.com |
|
From: Sean M. <sea...@pr...> - 2002-02-02 19:49:36
|
Some import trickery going on in the xml.sax stuff seems to be tripping up jythonc. I think it is down to the fact that at run-time, the SAX stuff goes hunting in a drivers2 directory looking for drivers. If it cannot find such a directory it complains saying "no parsers found". Here is a little program that illustrates the problem. It works fine with jython but does not work after compilation to a jar file with jythonc. """ test.py """ from xml import sax from xml.sax.xmlreader import InputSource class SAXEventDispatcher (sax.ContentHandler): pass parser = sax.make_parser(["xml.sax.drivers2.drv_xmlproc"]) print parser I am compiling to a jar and executing like this: java -cp %CLASSPATH%;test.jar test The traceback looks like this: Traceback (innermost last): File "D:\test.py", line 0, in main File "D:\xpipe\jython\Lib\xml\sax\sax2exts.py", line 0, in make_parser File "D:\xpipe\jython\Lib\xml\sax\saxexts.py", line 0, in make_parser SAXReaderNotAvailable: No parsers found Exception in thread "main" Executing directly with jython produces: <xml.sax.drivers2.drv_xmlproc.XmlprocDriver instance at 7037053> Any help greatly appreciated. Sean |
|
From: Sean M. <sea...@pr...> - 2002-02-02 15:13:25
|
Bill, Thanks for this. I've read about direct tweaking from the shell of CVS files to keep history across renames but it not an option using SourceForge. Having said that (picture the bleary eyes), I've already reorganized EVERYTHING. It has not been pleasant - such drudgery. I'm also now using Java naming conventions for all class and method names. It involved changing nearly every line of code in the whole system, Java, Jython, XML, RNG - everything was affected. I thought it best to do it now before a reorg became beyond consideration. Also, I've started a build.xml for ANT for building the distribution. (The mascot for XPipe by the way is the Leaf Cutter Ant http://www.lpzoo.com/tour/factsheets/herps/ant.html so use of the Ant building tool was of course obligatory.) All code now revolves around xpipe.net. net.xpipe is the Java and Jython package name for everything. Much fun but not yet much new code as it has taken ages to get everything working again after the reorg. I have a simple XPipe model working. As soon as I can chain some XComponents together and execute'em, I'm declaring a 0.6! Anon. Sean At 14:55 02/02/2002 +0000, =?US-ASCII?Q?Bill_de_hOra?= wrote: > > Sean McGrath > > > > Having discussed source code hierarchy organization with David Starr > > and others, and having had my > > ears burned about Java Code Conventions from various quarters > > :-), I have > > decided to bite the bullet > > and do a major code re-org around the domain name xpipe.net. > > > > CVS does not make it easy to rename files never mind wholesale > > rearrange directory structures. > > All the more reason to put a reasonable structure in place > > now that can > > last us into 1.0 and > > beyond. > >There is a way to move files around a cvs repository and keep history >(hard to tell whether this a feature of cvs or java package spaces), but >you need to be able to work on the repository files (using cp) directly >rather than go through cvs. But my understanding is that you can only >access your source via cvs on sourceforge (I know one admin who's gone >through pain more than once rejigging directories for java source). > >But strictly speaking java package spaces are a logical structure for >controlling dependency and build; you don't _need_ to have a directory >per package for Java source, but it's idiomatic to do so. I just ran a >test with Ant (which is what netBeans uses) and it will compile Java >classes from various package spaces stored in a single directory (it >creates the corresponding directory structure of class files). If the >package structure is in flux, maybe just leave the source in one >directory for now (and honestly, who cares about idiom if it's holding >you back?). > >Regards, >Bill de hOra > > >_______________________________________________ >Xpipe-developers mailing list >Xpi...@li... >https://lists.sourceforge.net/lists/listinfo/xpipe-developers http://www.propylon.com |
|
From: <de...@ei...> - 2002-02-02 15:00:18
|
> Sean McGrath > > Having discussed source code hierarchy organization with David Starr > and others, and having had my > ears burned about Java Code Conventions from various quarters > :-), I have > decided to bite the bullet > and do a major code re-org around the domain name xpipe.net. > > CVS does not make it easy to rename files never mind wholesale > rearrange directory structures. > All the more reason to put a reasonable structure in place > now that can > last us into 1.0 and > beyond. There is a way to move files around a cvs repository and keep history (hard to tell whether this a feature of cvs or java package spaces), but you need to be able to work on the repository files (using cp) directly rather than go through cvs. But my understanding is that you can only access your source via cvs on sourceforge (I know one admin who's gone through pain more than once rejigging directories for java source). But strictly speaking java package spaces are a logical structure for controlling dependency and build; you don't _need_ to have a directory per package for Java source, but it's idiomatic to do so. I just ran a test with Ant (which is what netBeans uses) and it will compile Java classes from various package spaces stored in a single directory (it creates the corresponding directory structure of class files). If the package structure is in flux, maybe just leave the source in one directory for now (and honestly, who cares about idiom if it's holding you back?). Regards, Bill de hOra |
1 message has been excluded from this view by a project administrator.
