xpipe-users — Users of the XPipe system

Re: [Xpipe-users] Starting with XPipe

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

At 11:42 14/10/2003 +0100, Sergey Beryozkin wrote:

>Thanks for explaining concepts behind XGrid.
>www.enterpriseintegrationpatterns.com have also a good explanation of
>Scatter/Gather patterns.
>So, XGrid is something which allows declaratively to set up multiple stages
>(XPipes) through which scattered doc fragments could be pumped through and
>eventually gathered ?

I think of XGrid more as a deployment pattern for XPipes. If you write an XPipe
engine so that it can harness multiple independent CPUs using, for example,
P2P methods, then it is an XGrid.

I'm travelling and on hols a bit for next two weeks and I'm going cold 
turkey on
e-mail. Back in two weeks (from next week.)

Sean

Re: [Xpipe-users] Starting with XPipe

[Sergey B. <sbe...@za...>]

Hi,
> You just need an engine to exectute an XPipe. If you want to execute an
> XComponent
> directly, you can just 'wrap' it in an XPipe shell before passing it to
the
> execution
> engine. That way, there is no need for the core engine to know anything
> other than how to execute an XPipe.
How does the core engine execute an XPipe ? Does it ask an XPipe to execute
itself, which then executes every XComponent by getting its code properties
?

Thanks for explaining concepts behind XGrid.
www.enterpriseintegrationpatterns.com have also a good explanation of
Scatter/Gather patterns.
So, XGrid is something which allows declaratively to set up multiple stages
(XPipes) through which scattered doc fragments could be pumped through and
eventually gathered ?
Interesting, it looks similar to an XRig fork and join. If so, then an XGrid
could be a lower-level implementation of XRig's higher-level fork and join
constructs. What do you think ?

Cheers
Sergey

Re: [Xpipe-users] Starting with XPipe

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

At 09:55 14/10/2003 +0100, Sergey Beryozkin wrote:
> > What is a preferred execution model for XComponents ?
>
>That was probably a silly question. I know that for XComponent to be
>executed it has to be inserted in XPipe, and XPipe engine will execute it.
>I'm just thinking about cooking up my own simple execution engine, if time
>allows.  My thinking was that because XPipe is just a sequence/composite
>list of XComponents, then an execution engine can execute both XPipe and
>XComponent, the same way as JUnit TestRunner can execute TestSuite and
>TestCase. Any other Composite exampel will do as well.

You just need an engine to exectute an XPipe. If you want to execute an 
XComponent
directly, you can just 'wrap' it in an XPipe shell before passing it to the 
execution
engine. That way, there is no need for the core engine to know anything
other than how to execute an XPipe.

>By the way, what is XGrid ?

XML processing, when approaches in term of data flow and pipelines, becomes 
what is
known in parallel computing circles as "trivially parallelisable". i.e. you 
can be pumping
many documents through a pipe at the same time and the execution of stage X 
for document A
is completely unrelated to the execution of stage X for document B. Given 
lots of processors
to do the work, you can get serious throughput this way.

Grid technology is a term increasingly used to describe the notion of 
computational power
available 'on tap'. I think it has a huge future for XML processing.

Note that a common objection to XGrid concept is that all the stages of 
processing document A have
to happen in order. So, if you have a small volume of large documents, 
XGrid buys you very little.

This would be true if not for the fact that most real world XML processing 
tasks operate on a segmented
view of an XML document. e.g. Customer by customer, chapter by chapter, 
widget by widget.

These segments - micro-documents can be processed independently. The 
scatter/gather concept discussed
in the powerpoint on the xpipe site talks about how two XComponents - 
scatter and gather - can work together
to allow documents to be split into segments (scattered) at 'fulcrum' 
points for the purposes of work distribution on
an XGrid and then re-assembled (gathered) before popping out of the end of 
a processing pipeline.

Sean

http://seanmcgrath.blogspot.com

Re: [Xpipe-users] Starting with XPipe

[Sergey B. <sbe...@za...>]

> What is a preferred execution model for XComponents ?

That was probably a silly question. I know that for XComponent to be
executed it has to be inserted in XPipe, and XPipe engine will execute it.
I'm just thinking about cooking up my own simple execution engine, if time
allows.  My thinking was that because XPipe is just a sequence/composite
list of XComponents, then an execution engine can execute both XPipe and
XComponent, the same way as JUnit TestRunner can execute TestSuite and
TestCase. Any other Composite exampel will do as well.
For this to work I'd probably add  abstract class AbstractXComponent, with
both XComponent and XPipe inheriting from it. Or may be, XRunnable interface
with a method like run(InputStream, OutputStream) could be implemented by
XPipe, XCompoment and even XRig. There's still a question where XComponent
will get an execution environment from, perhaps it can obtain it from some
Registry or Factory which would return a (cached) instance of XExecutor
based on XComponent code configuration. The same applies to pre and post
validators. All existing XComponent methods are fine, they're very useful
for a building tool.
It may not be a good idea, but this is just my first cut.
By the way, what is XGrid ?

Thanks
Sergey Beryozkin

Re: [Xpipe-users] Starting with XPipe

[Sergey B. <sbe...@za...>]

Hi,
What is a preferred execution model for XComponents ?
I checked the source code, it seems an engine concentrates in itself the
execution behaviour by quering XComponent, rather than asking an XComponent
to  execute itself.
Are there any objections to XComponents being responsible for their own
execution ?
Thanks
Sergey Beryozkin

Re: [Xpipe-users] Starting with XPipe

[Sergey B. <sbe...@za...>]

> >Another question : what is XRing ? Is it a process manager which allows
to
> >build complex XPipes structures?
>
> XRig is just an idea at the moment.

Sorry for an extra 'n' :-)

>The idea is to provide a way of hooking
> up a collection of linear workflows (pipes) to do things that require more
> complex flows of control e.g. branching, looping etc.
It looks like a process manager. Or, may be XRig could be categorized better
as 'complex activity', while a process manager would coordinate XRig
instances with requests

Thanks
Sergey

Re: [Xpipe-users] Starting with XPipe

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

At 10:47 13/10/2003 +0100, Sergey Beryozkin wrote:
>Sean,
>
>Thanks for your answer,
>What handler types can be used by XComponents ?  I mean is it an XSLT
>transformation and Java class instances only ? Are Jython scripts allowed ?

Java, Jython + XSLT + Exec (which is anything else).

>Actually, I've just looked at xcomponent.rng, and I see 4 types : Java,
>XSLT, EXEC and Jython.

Yes.

>Can you please explain me about "pre" and "post". Schema says it could be
>Java class, Jython, XSD, RNG or DTD. Are 'pre'  and 'post' used for input
>and output validation ?

Yes. Ideas from "design by contract" to allow you to be sure that input XML 
meets some input predicate and be sure that the output matches an output 
predicate.

>Another question : what is XRing ? Is it a process manager which allows to
>build complex XPipes structures?

XRig is just an idea at the moment. The idea is to provide a way of hooking 
up a collection of linear workflows (pipes) to do things that require more 
complex flows of control e.g. branching, looping etc.

Sean

Re: [Xpipe-users] Starting with XPipe

[Sergey B. <sbe...@za...>]

Sean,

Thanks for your answer,
What handler types can be used by XComponents ?  I mean is it an XSLT
transformation and Java class instances only ? Are Jython scripts allowed ?
Actually, I've just looked at xcomponent.rng, and I see 4 types : Java,
XSLT, EXEC and Jython.
Can you please explain me about "pre" and "post". Schema says it could be
Java class, Jython, XSD, RNG or DTD. Are 'pre'  and 'post' used for input
and output validation ?
Another question : what is XRing ? Is it a process manager which allows to
build complex XPipes structures?

Thanks
Sergey Beryozkin



----- Original Message -----
From: "Sean McGrath" <sea...@pr...>
To: <xpi...@li...>
Sent: Friday, October 10, 2003 9:01 AM
Subject: Re: [Xpipe-users] Starting with XPipe


> At 18:04 19/09/2003 +0100, Siarhei Biarozkin wrote:
> >Hello,
> >
> >What is the best way to test an individual XPipe instance ?
> >Is a custom engine needed so that it could process an XPipe instance
> >description according to its schema, do the same with individual
> >XComponents, and then run a sequence ?
>
> The best way to test an XComponent is to put it into its own pipe. That
way it
> becomes "executable" using any XPipe engine. (There are only two that I
> know of, the CLI jython application
> on sourceforge an Propylon's commercial one).
>
> >Is it XPipes 0.6 which is the last version ? It seems to be quite old
>
> Yes it is and yes it is old. All contributions to move the code forward
> gratefully received:-)
>
> regards,
> Sean
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> SourceForge.net hosts over 70,000 Open Source Projects.
> See the people who have HELPED US provide better services:
> Click here: http://sourceforge.net/supporters.php
> _______________________________________________
> Xpipe-users mailing list
> Xpi...@li...
> https://lists.sourceforge.net/lists/listinfo/xpipe-users
>
>

Re: [Xpipe-users] Starting with XPipe

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

At 18:04 19/09/2003 +0100, Siarhei Biarozkin wrote:
>Hello,
>
>What is the best way to test an individual XPipe instance ?
>Is a custom engine needed so that it could process an XPipe instance
>description according to its schema, do the same with individual
>XComponents, and then run a sequence ?

The best way to test an XComponent is to put it into its own pipe. That way it
becomes "executable" using any XPipe engine. (There are only two that I 
know of, the CLI jython application
on sourceforge an Propylon's commercial one).

>Is it XPipes 0.6 which is the last version ? It seems to be quite old

Yes it is and yes it is old. All contributions to move the code forward 
gratefully received:-)

regards,
Sean

[Xpipe-users] Starting with XPipe

[Siarhei B. <sbe...@za...>]

Hello,

What is the best way to test an individual XPipe instance ?
Is a custom engine needed so that it could process an XPipe instance
description according to its schema, do the same with individual
XComponents, and then run a sequence ?
Is it XPipes 0.6 which is the last version ? It seems to be quite old

Thanks
Sergey Beryozkin

[Xpipe-users] Anti-SPAM measure - all posts now need approval

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

Notice:

Postings to the XPipe developers and users lists are now approved on a message
by message basis to cut out the spam that has been growing lately.

regards,
list admistrator
Sean McGrath

[Xpipe-users] Problems with Geocrawler mailing list archives

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

Sourceforge are having some problems with the Geocrawler e-mail archiver at 
the moment so
those related to XPipe are a bit behind.

The integrated Sourceforge mail archives seem up to date though.

Developers:
	http://sourceforge.net/mailarchive/forum.php?forum_id=2988

Users:
	http://sourceforge.net/mailarchive/forum.php?forum_id=7700

regards,
Sean

[Xpipe-users] Workflows and XPipes

[Tony R. <ton...@pr...>]

I'm interested in the concept of an XPipe as a workflow engine. Obviously
any assembly line is a workflow (I'm sure Henry Ford would agree) but some
of the bigger workflow engines out there have things like event driven
processes within the flow (e.g. the car is only painted once the body is
welded together) and parallel workflow (e.g. while the car is being welded
together, the seats are being made).
	Do such complexities break the simplicity of the xpipe model or is it
possible to write some XComponents that essentially allow event and parallel
workflows? One of the things I was thinking about is that in say a parallel
workflow, each assembly line is a pipe and multiple pipes connected together
via some kind of logic would suggest a parallel workflow of sorts. If we
take that concept one step higher, then we're going to have a situation
where many different pipes can be connected to many different pipes. Thus an
xpipe has the potential to be a workflow engine. A workflow engine where
each process is simple and possible to re-use.. Lots of big vendors in that
space though....

T.

[Xpipe-users] Bravo XPipe!

[Roger L. C. <cos...@mi...>]

I have been looking at the XML Pipeline Language...

XPipe, IMHO, is much superior...

Sean, you really need to get this xpipe stuff implemented, and
marketed.  It's good stuff!

/Roger

[Xpipe-users] Re: [Schematron-love-in] the best solution

[Mr F. S. <SIL...@CN...>]

>>> "Othman Haddad" <oh...@ne...> 06/25/02 09:07AM >>>
>=20
> the processing and validation of an xml document on the server side in =
an
> assembly line is really interesting (i mean something like:=20
>
> xm document->Schema w3c validation->Schematron validation->databinding =
to
> java...)

I am trying to do something like this.


> the problem is: if i want to check for validation just behind the =
browser
> where i write my xml document, i don't find any other way than doing =
using
> javascript...

I don't think anyone has implemented Schematron or XSLT in Javascript.
How do you write an XML document on a browser, anyway?

In my application the date comes from a form, which results in a servlet =
request
object, not an XML file.  The servelet has to create the XML file from the =
servlet
request object, so the same servlet can then call for validation.  If =
valid, it can
then pass the data from the servlet request object, as XML or in some =
other form,
to the back end.


> so is there anyway to check for validation in the browser using Schema =
W3C
> and Schematron before sending the xml to the server?

If you absolutely must validate on the browser, I cannot think of any way =
to do
this except maybe via a Java applet.

Re: [Xpipe-users] jdk 1.4?

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

At 11:35 25/06/2002 +0200, Othman Haddad wrote:
>i don't if the problem:
>Traceback (innermost last):
>   File "InstallXPipe.py", line 11, in ?
>ImportError: no module named java
>
>is because i'm working on jdk1.4 platform?!!

Possibly. I have not moved to JDK 1.4 yet. Any JDK 1.4/XPipe users
out there?

Sean

Re: [Xpipe-users] xpipe installation

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

At 17:37 24/06/2002 +0200, Othman Haddad wrote:
>hi everybody,
>i don't manage to install xpipe and i don't know what is wrong?; here it 
>is what i've done:
>1) i've installed the jpython.
>2) i've tried to execute the command i've found on the readme file:
>-->
>jython InstallXPipe.py xp0.xpi testdir
>
>but iget this error message:
>-->
>  Traceback (innermost last):
>   File "..\src\jython\src\net\xpipe\InstallXPipe.py", line 11, in ?
>ImportError: no module named java
>
>i'm new to xpipes, and i don't see yet why installing it is so bothering 
>and need to much to do?
>can you help me please or recommend a detailed installation site of xpipes 
>with jython?
>
Best to work through the Jython installation and insure that it is working 
fine first.
You should be able to run Jython and get to its interactive prompt. From
there you can try to import some standard java modules. This will
tell you a lot about how you system is set up.

regards,
Sean

Re: [Xpipe-users] Competitor to XPipe?

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

Roger,

Propylon, the company I work for, are co-submitters to the Pipeline
proposal. We intend to contribute to whatever activity grows
out of it.

The proposal as it stands is just a proposal and will grow and mutate
over time. I'm looking forward to putting forward XPipe as
complimentary to the existing W3C Note. I.e. it describes the
dependancies between resources. An engine can work from this
description of dependancies to a list of components to be
executed in a sequence. The components and the execution
is something I believe XPipe does well. The dependancy graph
resolution is something that the likes of Ant, Make etc. do
well.
I see the two naturally fitting together rather than competing.

As for Flow Based Programming - well worth a read and highly
recommended - most of the book is published in the
web site.

Sean


At 10:09 07/03/2002 -0500, Roger L. Costello wrote:
>XML Pipeline Definition Language introduced as Note
>http://xmlhack.com/read.php?item=1564
>
>   The W3C has released XML Pipeline Definition Language, which
>   describes "the processing relationships between XML resources" as a
>   Note.
>   (XML, W3C: 28 Feb 2002)
>
>Also of interest:
>
> >Anyone remember Morrison's "Flow Based Programming" (Van Nostrum Reinhold,
> >1994)?  Fascinating stuff, which apparently he used very successfully at
> >IBM.  Sort of a cross between recursively structured streams, pipes,
> >potential parallel processing, and pull processes.  It ought be be well
> >suited to markup processing.  I think there are still a few copies of the
> >book to be found (maybe used).
>
> >It's available online http://www.jpaulmorrison.com/fbp/
>
>I just purchased a copy from amazon.
>/Roger
>
>
>_______________________________________________
>Xpipe-users mailing list
>Xpi...@li...
>https://lists.sourceforge.net/lists/listinfo/xpipe-users

http://www.propylon.com

[Xpipe-users] W3C's XML Pipeline Definition Language

[DuCharme, B. (LNG) <bob...@le...>]

I finally had a chance to read through the W3C XML Pipeline submission.
Because there was no location for public comment included, and because most
of the issues are related to XPipe, I thought I'd post my impressions here.
I'd like to hear what other people have to say.

Impressive list of submitters. 

1.4, the classification of processes into five classes was interesting. 

I like the processDef element, which "associates a name with an external
process definition." If a program that performs a task is upgraded or
replaced, only one pointer to it needs to be fixed, and the p:process
process definitions that use it can be left alone.

2.4.2.3: "It's an error for more than one process to produce the same
information set." How is that error caught? If process p1 turns infoset i1
into i2, and p2 turns i2 into p3, and p3 can turn i1 into i3, then processes
p2 and p3 are producing the same information set. Theoretically, p3 is
unnecessary, but practically, if p3 is being replaced by p1 + p2 or vice
versa, a period in which they're both in production is natural. 

My main issue with the Note is the processing dependency on infosets not
being up-to-date. I certainly understand the value of this make-like
checking of date-time stamps to determine which processes don't need to be
redone, but I'm not convinced that it deserves to be a part of the Pipeline
Definition Language, especially after reading the use cases. If this was not
in the spec (as it's not in XPipe) the pipeline requirements would be
simpler. Is there any reason a date-time stamp couldn't be passed in a
p:param element, giving the process the make-like time stamp to use in its
processing logic if desired while leaving the design of pipeline controller
simpler and cleaner (as it is in XPipe)?

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

[Xpipe-users] Competitor to XPipe?

[Roger L. C. <cos...@mi...>]

XML Pipeline Definition Language introduced as Note
http://xmlhack.com/read.php?item=1564

  The W3C has released XML Pipeline Definition Language, which
  describes "the processing relationships between XML resources" as a
  Note.
  (XML, W3C: 28 Feb 2002)

Also of interest:

>Anyone remember Morrison's "Flow Based Programming" (Van Nostrum Reinhold,
>1994)?  Fascinating stuff, which apparently he used very successfully at
>IBM.  Sort of a cross between recursively structured streams, pipes,
>potential parallel processing, and pull processes.  It ought be be well
>suited to markup processing.  I think there are still a few copies of the
>book to be found (maybe used).

>It's available online http://www.jpaulmorrison.com/fbp/

I just purchased a copy from amazon.
/Roger

Re: [Xpipe-users] Contribution: removeNamespace.xco

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

Roger,

Thanks. Can you send over the source files removeNamespace.java.
I'll test and add to the next release.

Sean


At 14:38 02/03/2002 -0500, Roger L. Costello wrote:
>Below is an xcomponent (implemented in Java) to strip out all namespaces
>in an xml document.  It will remove namespace declarations, and remove
>any namespace qualifiers on elements and attributes.  /Roger
>
>removeNamespace.xco
>
><xcomponent>
><version></version>
><title></title>
><keywords>
></keywords>
><authorInfo/>
><doc>
>
></doc>
><parameters>
></parameters>
><unitTests>
></unitTests>
><pre/>
><code type="JavaClass" encoding = "BASE64"  extractFilename =
>"removeNamespace.class" >
><![CDATA[
>yv66vgADAC0AoQoAMgBRCABSCQAvAFMJAC8AVAkALwBVCgAvAFYKAC8AVwoALwBYBwBZCgAJAFoH
>AFsKAAsAXAcAXQcAXgoADgBfCgANAGAKAAkAUQoACQBhCABiCgAJAGMKAA0AZAcAZQoAZgBnCgAL
>AGgHAGkHAGoKABoAXAcAawoAHABsCgAcAG0KABwAbgoAHABoCABvCgBwAHEKAHAAcgoALwBzCgBw
>AHQKAC8AdQoALwB2CgBwAHcKAHAAeAoACQBcCgBwAHkJAHoAewgAfAoAfQB+BwB/CgAvAFEKAC8A
>gAcAgQEADWlucHV0RmlsZW5hbWUBABJMamF2YS9sYW5nL1N0cmluZzsBAA5vdXRwdXRGaWxlbmFt
>ZQEAC2xvZ0ZpbGVuYW1lAQAHaXN0cmVhbQEAGUxqYXZhL2lvL0ZpbGVJbnB1dFN0cmVhbTsBAAdv
>c3RyZWFtAQAaTGphdmEvaW8vRmlsZU91dHB1dFN0cmVhbTsBAAdsc3RyZWFtAQADbHB3AQAVTGph
>dmEvaW8vUHJpbnRXcml0ZXI7AQAGPGluaXQ+AQADKClWAQAEQ29kZQEAD0xpbmVOdW1iZXJUYWJs
>ZQEAB3Byb2Nlc3MBABYoW0xqYXZhL2xhbmcvU3RyaW5nOylJAQAHZ2V0RmlsZQEAJihMamF2YS9s
>YW5nL1N0cmluZzspTGphdmEvbGFuZy9TdHJpbmc7AQAJd3JpdGVGaWxlAQAnKExqYXZhL2xhbmcv
>U3RyaW5nO0xqYXZhL2xhbmcvU3RyaW5nOylWAQAPc3RyaXBOYW1lc3BhY2VzAQASZ2V0TmFtZXNw
>YWNlUHJlZml4AQAZc3RyaXBOYW1lc3BhY2VEZWNsYXJhdGlvbgEAGHN0cmlwTmFtZXNwYWNlUXVh
>bGlmaWVycwEAOChMamF2YS9sYW5nL1N0cmluZztMamF2YS9sYW5nL1N0cmluZzspTGphdmEvbGFu
>Zy9TdHJpbmc7AQAEbWFpbgEAFihbTGphdmEvbGFuZy9TdHJpbmc7KVYBAApTb3VyY2VGaWxlAQAU
>cmVtb3ZlTmFtZXNwYWNlLmphdmEMAD4APwEAAAwAMwA0DAA1ADQMADYANAwARABFDABIAEUMAEYA
>RwEAFmphdmEvbGFuZy9TdHJpbmdCdWZmZXIMAD4AggEAF2phdmEvaW8vRmlsZUlucHV0U3RyZWFt
>DAA+AIMBABZqYXZhL2lvL0J1ZmZlcmVkUmVhZGVyAQAZamF2YS9pby9JbnB1dFN0cmVhbVJlYWRl
>cgwAPgCEDAA+AIUMAIYAhwEAAg0KDACIAIkMAIoAiQEAE2phdmEvbGFuZy9FeGNlcHRpb24HAIsM
>AIwAPwwAjQA/AQATamF2YS9pby9JT0V4Y2VwdGlvbgEAGGphdmEvaW8vRmlsZU91dHB1dFN0cmVh
>bQEAE2phdmEvaW8vUHJpbnRXcml0ZXIMAD4AjgwAjwCDDACQAD8BAAV4bWxucwcAkQwAkgCTDACU
>AJUMAEkARQwAlACWDABKAEUMAEsATAwAlwCYDACSAJkMAJoAmwcAnAwAnQCeAQA6VXNhZ2U6ICBy
>ZW1vdmVOYW1lc3BhY2UgPElucHV0RmlsZT4gPE91dHB1dEZpbGU+IDxMb2dGaWxlPgcAnwwAoACD
>AQAPcmVtb3ZlTmFtZXNwYWNlDABCAEMBABBqYXZhL2xhbmcvT2JqZWN0AQAEKEkpVgEAFShMamF2
>YS9sYW5nL1N0cmluZzspVgEAGChMamF2YS9pby9JbnB1dFN0cmVhbTspVgEAEyhMamF2YS9pby9S
>ZWFkZXI7KVYBAAZhcHBlbmQBACwoTGphdmEvbGFuZy9TdHJpbmc7KUxqYXZhL2xhbmcvU3RyaW5n
>QnVmZmVyOwEACHRvU3RyaW5nAQAUKClMamF2YS9sYW5nL1N0cmluZzsBAAhyZWFkTGluZQEAE2ph
>dmEvbGFuZy9UaHJvd2FibGUBAA9wcmludFN0YWNrVHJhY2UBAAVjbG9zZQEAGShMamF2YS9pby9P
>dXRwdXRTdHJlYW07KVYBAAVwcmludAEABWZsdXNoAQAQamF2YS9sYW5nL1N0cmluZwEAB2luZGV4
>T2YBABUoTGphdmEvbGFuZy9TdHJpbmc7KUkBAAlzdWJzdHJpbmcBABUoSSlMamF2YS9sYW5nL1N0
>cmluZzsBABYoSUkpTGphdmEvbGFuZy9TdHJpbmc7AQAGY2hhckF0AQAEKEkpQwEABChJKUkBAAZs
>ZW5ndGgBAAMoKUkBABBqYXZhL2xhbmcvU3lzdGVtAQADb3V0AQAVTGphdmEvaW8vUHJpbnRTdHJl
>YW07AQATamF2YS9pby9QcmludFN0cmVhbQEAB3ByaW50bG4AIQAvADIAAAAHAAIAMwA0AAAAAgA1
>ADQAAAACADYANAAAAAIANwA4AAAAAgA5ADoAAAACADsAOgAAAAIAPAA9AAAACQABAD4APwABAEAA
>AAA/AAIAAQAAABcqtwABKhICtQADKhICtQAEKhICtQAFsQAAAAEAQQAAABYABQAAAA4ABAAPAAoA
>EAAQABEAFgASAAEAQgBDAAEAQAAAAFYAAwADAAAAKiorAzK1AAMqKwQytQAEKisFMrUABSq0AAO4
>AAZNKrQABCy4AAe4AAgErAAAAAEAQQAAABoABgAAABUABwAWAA4AFwAVABkAHQAaACgAHAAJAEQA
>RQABAEAAAADmAAUACQAAAIIBTAFNuwAJWREIALcACk4BOgS7AAtZKrcADEy7AA1ZuwAOWSu3AA+3
>ABBNpwAcLbsACVm3ABEZBLYAEhITtgAStgAUtgASTiy2ABVZOgTH/+CoABunACk6BRkFtgAXqAAO
>pwAcOgaoAAYZBr86ByvGAAwrtgAYpwAFOgipBy22ABSwAAMAEgBRAFcAFgASAGQAZAAAAHIAdgB5
>ABkAAQBBAAAAOgAOAAAAIAACACEABAAiAA8AIwASACUAGwAmACsAJwAuACgARwAnAFcAKwBkAC0A
>cgAvAHkAMAB9ADIACQBGAEcAAQBAAAAAYAADAAQAAAAouwAaWSq3ABtNuwAcWSy3AB1OLSu2AB4t
>tgAfLbYAIKcACE0stgAXsQABAAAAHwAiABYAAQBBAAAAHgAHAAAANwAJADgAEgA5ABcAOgAbADsA
>IgA8ACcAPQAJAEgARQABAEAAAACzAAQABQAAAGsqEiG2ACI8GwKgAAUqsLsACVm3ABFNKhu2ACO4
>ACROLccAIywqAxu2ACW2ABJXLCobtgAjuAAmtgASVyy2ABS4AAewLCoDG7YAJbYAElcsKhu2ACO4
>ACa2ABJXLLYAFC24ACc6BBkEuAAHsAAAAAEAQQAAADYADQAAAEAABwBBAAwAQgAOAEQAFgBGAB8A
>RwAjAEgALgBJADsASgBDAE0ATgBOAFsATwBlAFAACQBJAEUAAQBAAAAAXwADAAMAAAAvKgi2ACgQ
>Op8ABQGwKhAgtgApPCoQPbYAKT0bHKIACyoQBhu2ACWwKhAGHLYAJbAAAAABAEEAAAAeAAcAAABW
>AAoAVwAMAFkAEwBaABoAWwAfAFwAJwBfAAkASgBFAAEAQAAAAEIAAwAEAAAAHioQIrYAKTwqGwRg
>tgAjTSwQIrYAKT4sHQRgtgAjsAAAAAEAQQAAABIABAAAAGUABwBmAA8AZwAWAGgACQBLAEwAAQBA
>AAAAYQAFAAQAAAA1Kiu2ACI9HAKgAAUqsLsACVkqAxy2ACW3ACpOLSocK7YAK2AEYLYAI7YAElct
>tgAUK7gAJ7AAAAABAEEAAAAaAAYAAABsAAYAbQALAG4ADQBwABsAcQAsAHIACQBNAE4AAQBAAAAA
>SgACAAIAAAAeKr4GnwAMsgAsEi22AC6xuwAvWbcAMEwrKrYAMVexAAAAAQBBAAAAGgAGAAAAdgAG
>AHcADgB4AA8AegAXAHsAHQB8AAEATwAAAAIAUA==
>
>]]></code>
>
><post/>
><resources>
></resources>
></xcomponent>
>
>
>_______________________________________________
>Xpipe-users mailing list
>Xpi...@li...
>https://lists.sourceforge.net/lists/listinfo/xpipe-users

http://www.propylon.com

Re: [Xpipe-users] XComponent <parameters> working?

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

Roger,

Parameter passing is top of my list. It is the very next thing I'm going
to work on.

regards,
Sean

At 14:33 02/03/2002 -0500, Roger L. Costello wrote:
>I am trying to use the parameter element in xcomponents.  I have created
>an xcomponent which changes the name of an element, where the name of
>the element to be replaced and its replacement value are specified as a
>parameter [see the xcomponent below].  The problem is that the
>parameters don't seem to be getting to my xcomponent's code (a
>stylesheet).  Am I doing something wrong, or is it simply that
>parameters have not been implemented yet?
>
>My second question is more general, on how parameters get delivered to
>an xcomponent's code.  I assume that when the code is xslt the
>parameters get delivered just as stylesheet parameters.  Right?  What if
>the code is Java?  Do the parameters get delivered as parameters to the
>main routine, i.e.,
>
>public static void main(String[] args)
>
>The parameters will be in the args array?
>
>As I dig deeper I am getting more and more excited about this
>technology.  This is the right approach I feel.  I wish that I had the
>time to help implement the core pieces.  Timeliness is crucial, I
>think.  /Roger
>
>changeElementName.xco
>
><xcomponent>
><version>0.1</version>
><title>Change Element Name - XSLT</title>
><keywords>
>         <keyword>XSLT</keyword>
>         <keyword>Change Element Name</keyword>
></keywords>
><authorInfo>
>     Roger L. Costello
></authorInfo>
>
><doc>
><h1>Change Element Name</h1>
><p>Change the name of an element</p>
></doc>
>
><parameters>
>     <parameter
>name="nameOfElementToChange">WorldFactbookReferenceDeskRequest</parameter>
>     <parameter
>name="newNameOfElement">WorldFactbookReferenceDeskRequestResults</parameter>
></parameters>
>
><unitTests>
>         <test name ="First Test">
>                 <parameters>
>                     <parameter
>name="nameOfElementToChange">foo</parameter>
>                     <parameter name="newNameOfElement">bar</parameter>
>                 </parameters>
>                 <pre/>
>                 <input href="#unitTestFile1"/>
>                 <output href="#unitTestFile2"/>
>                 <post/>
>         </test>
></unitTests>
>
><pre/>
><code type="XSLT" encoding="PLAIN" extractFilename=""
>CLASSPATH=""><![CDATA[
><!-- Change the name of an element -->
><xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>                 version="1.0">
>
>     <xsl:output method="xml"/>
>     <xsl:param name="nameOfElementToChange"/>
>     <xsl:param name="newNameOfElement"/>
>
>     <xsl:template match="*">
>         <xsl:if test="name(.) != $nameOfElementToChange">
>             <xsl:element name="{name(.)}">
>                 <xsl:for-each select="@*">
>                     <xsl:attribute name="{name(.)}">
>                         <xsl:value-of select="."/>
>                     </xsl:attribute>
>                 </xsl:for-each>
>                 <xsl:apply-templates/>
>             </xsl:element>
>         </xsl:if>
>         <xsl:if test="name(.) = $nameOfElementToChange">
>             <xsl:element name="{$newNameOfElement}">
>                 <xsl:for-each select="@*">
>                     <xsl:attribute name="{name(.)}">
>                         <xsl:value-of select="."/>
>                     </xsl:attribute>
>                 </xsl:for-each>
>                 <xsl:apply-templates/>
>             </xsl:element>
>         </xsl:if>
>     </xsl:template>
>
></xsl:stylesheet>
>]]>
></code>
><post/>
>
><resources>
><resource id = "unitTestFile1">
><![CDATA[
><?xml version="1.0"?>
><test isIt="true"><foo>Hello World</foo></test>
>]]>
></resource>
>
><resource id = "unitTestFile2">
><![CDATA[
><?xml version="1.0"?>
><test isIt="true"><bar>Hello World</bar></test>
>]]>
></resource>
></resources>
>
></xcomponent>
>
>
>_______________________________________________
>Xpipe-users mailing list
>Xpi...@li...
>https://lists.sourceforge.net/lists/listinfo/xpipe-users

http://www.propylon.com

[Xpipe-users] Contribution: removeNamespace.xco

[Roger L. C. <cos...@mi...>]

Below is an xcomponent (implemented in Java) to strip out all namespaces
in an xml document.  It will remove namespace declarations, and remove
any namespace qualifiers on elements and attributes.  /Roger

removeNamespace.xco

<xcomponent>
<version></version>
<title></title>
<keywords>
</keywords>
<authorInfo/>
<doc>

</doc>
<parameters>
</parameters>
<unitTests>
</unitTests>
<pre/>
<code type="JavaClass" encoding = "BASE64"  extractFilename =
"removeNamespace.class" >
<![CDATA[
yv66vgADAC0AoQoAMgBRCABSCQAvAFMJAC8AVAkALwBVCgAvAFYKAC8AVwoALwBYBwBZCgAJAFoH
AFsKAAsAXAcAXQcAXgoADgBfCgANAGAKAAkAUQoACQBhCABiCgAJAGMKAA0AZAcAZQoAZgBnCgAL
AGgHAGkHAGoKABoAXAcAawoAHABsCgAcAG0KABwAbgoAHABoCABvCgBwAHEKAHAAcgoALwBzCgBw
AHQKAC8AdQoALwB2CgBwAHcKAHAAeAoACQBcCgBwAHkJAHoAewgAfAoAfQB+BwB/CgAvAFEKAC8A
gAcAgQEADWlucHV0RmlsZW5hbWUBABJMamF2YS9sYW5nL1N0cmluZzsBAA5vdXRwdXRGaWxlbmFt
ZQEAC2xvZ0ZpbGVuYW1lAQAHaXN0cmVhbQEAGUxqYXZhL2lvL0ZpbGVJbnB1dFN0cmVhbTsBAAdv
c3RyZWFtAQAaTGphdmEvaW8vRmlsZU91dHB1dFN0cmVhbTsBAAdsc3RyZWFtAQADbHB3AQAVTGph
dmEvaW8vUHJpbnRXcml0ZXI7AQAGPGluaXQ+AQADKClWAQAEQ29kZQEAD0xpbmVOdW1iZXJUYWJs
ZQEAB3Byb2Nlc3MBABYoW0xqYXZhL2xhbmcvU3RyaW5nOylJAQAHZ2V0RmlsZQEAJihMamF2YS9s
YW5nL1N0cmluZzspTGphdmEvbGFuZy9TdHJpbmc7AQAJd3JpdGVGaWxlAQAnKExqYXZhL2xhbmcv
U3RyaW5nO0xqYXZhL2xhbmcvU3RyaW5nOylWAQAPc3RyaXBOYW1lc3BhY2VzAQASZ2V0TmFtZXNw
YWNlUHJlZml4AQAZc3RyaXBOYW1lc3BhY2VEZWNsYXJhdGlvbgEAGHN0cmlwTmFtZXNwYWNlUXVh
bGlmaWVycwEAOChMamF2YS9sYW5nL1N0cmluZztMamF2YS9sYW5nL1N0cmluZzspTGphdmEvbGFu
Zy9TdHJpbmc7AQAEbWFpbgEAFihbTGphdmEvbGFuZy9TdHJpbmc7KVYBAApTb3VyY2VGaWxlAQAU
cmVtb3ZlTmFtZXNwYWNlLmphdmEMAD4APwEAAAwAMwA0DAA1ADQMADYANAwARABFDABIAEUMAEYA
RwEAFmphdmEvbGFuZy9TdHJpbmdCdWZmZXIMAD4AggEAF2phdmEvaW8vRmlsZUlucHV0U3RyZWFt
DAA+AIMBABZqYXZhL2lvL0J1ZmZlcmVkUmVhZGVyAQAZamF2YS9pby9JbnB1dFN0cmVhbVJlYWRl
cgwAPgCEDAA+AIUMAIYAhwEAAg0KDACIAIkMAIoAiQEAE2phdmEvbGFuZy9FeGNlcHRpb24HAIsM
AIwAPwwAjQA/AQATamF2YS9pby9JT0V4Y2VwdGlvbgEAGGphdmEvaW8vRmlsZU91dHB1dFN0cmVh
bQEAE2phdmEvaW8vUHJpbnRXcml0ZXIMAD4AjgwAjwCDDACQAD8BAAV4bWxucwcAkQwAkgCTDACU
AJUMAEkARQwAlACWDABKAEUMAEsATAwAlwCYDACSAJkMAJoAmwcAnAwAnQCeAQA6VXNhZ2U6ICBy
ZW1vdmVOYW1lc3BhY2UgPElucHV0RmlsZT4gPE91dHB1dEZpbGU+IDxMb2dGaWxlPgcAnwwAoACD
AQAPcmVtb3ZlTmFtZXNwYWNlDABCAEMBABBqYXZhL2xhbmcvT2JqZWN0AQAEKEkpVgEAFShMamF2
YS9sYW5nL1N0cmluZzspVgEAGChMamF2YS9pby9JbnB1dFN0cmVhbTspVgEAEyhMamF2YS9pby9S
ZWFkZXI7KVYBAAZhcHBlbmQBACwoTGphdmEvbGFuZy9TdHJpbmc7KUxqYXZhL2xhbmcvU3RyaW5n
QnVmZmVyOwEACHRvU3RyaW5nAQAUKClMamF2YS9sYW5nL1N0cmluZzsBAAhyZWFkTGluZQEAE2ph
dmEvbGFuZy9UaHJvd2FibGUBAA9wcmludFN0YWNrVHJhY2UBAAVjbG9zZQEAGShMamF2YS9pby9P
dXRwdXRTdHJlYW07KVYBAAVwcmludAEABWZsdXNoAQAQamF2YS9sYW5nL1N0cmluZwEAB2luZGV4
T2YBABUoTGphdmEvbGFuZy9TdHJpbmc7KUkBAAlzdWJzdHJpbmcBABUoSSlMamF2YS9sYW5nL1N0
cmluZzsBABYoSUkpTGphdmEvbGFuZy9TdHJpbmc7AQAGY2hhckF0AQAEKEkpQwEABChJKUkBAAZs
ZW5ndGgBAAMoKUkBABBqYXZhL2xhbmcvU3lzdGVtAQADb3V0AQAVTGphdmEvaW8vUHJpbnRTdHJl
YW07AQATamF2YS9pby9QcmludFN0cmVhbQEAB3ByaW50bG4AIQAvADIAAAAHAAIAMwA0AAAAAgA1
ADQAAAACADYANAAAAAIANwA4AAAAAgA5ADoAAAACADsAOgAAAAIAPAA9AAAACQABAD4APwABAEAA
AAA/AAIAAQAAABcqtwABKhICtQADKhICtQAEKhICtQAFsQAAAAEAQQAAABYABQAAAA4ABAAPAAoA
EAAQABEAFgASAAEAQgBDAAEAQAAAAFYAAwADAAAAKiorAzK1AAMqKwQytQAEKisFMrUABSq0AAO4
AAZNKrQABCy4AAe4AAgErAAAAAEAQQAAABoABgAAABUABwAWAA4AFwAVABkAHQAaACgAHAAJAEQA
RQABAEAAAADmAAUACQAAAIIBTAFNuwAJWREIALcACk4BOgS7AAtZKrcADEy7AA1ZuwAOWSu3AA+3
ABBNpwAcLbsACVm3ABEZBLYAEhITtgAStgAUtgASTiy2ABVZOgTH/+CoABunACk6BRkFtgAXqAAO
pwAcOgaoAAYZBr86ByvGAAwrtgAYpwAFOgipBy22ABSwAAMAEgBRAFcAFgASAGQAZAAAAHIAdgB5
ABkAAQBBAAAAOgAOAAAAIAACACEABAAiAA8AIwASACUAGwAmACsAJwAuACgARwAnAFcAKwBkAC0A
cgAvAHkAMAB9ADIACQBGAEcAAQBAAAAAYAADAAQAAAAouwAaWSq3ABtNuwAcWSy3AB1OLSu2AB4t
tgAfLbYAIKcACE0stgAXsQABAAAAHwAiABYAAQBBAAAAHgAHAAAANwAJADgAEgA5ABcAOgAbADsA
IgA8ACcAPQAJAEgARQABAEAAAACzAAQABQAAAGsqEiG2ACI8GwKgAAUqsLsACVm3ABFNKhu2ACO4
ACROLccAIywqAxu2ACW2ABJXLCobtgAjuAAmtgASVyy2ABS4AAewLCoDG7YAJbYAElcsKhu2ACO4
ACa2ABJXLLYAFC24ACc6BBkEuAAHsAAAAAEAQQAAADYADQAAAEAABwBBAAwAQgAOAEQAFgBGAB8A
RwAjAEgALgBJADsASgBDAE0ATgBOAFsATwBlAFAACQBJAEUAAQBAAAAAXwADAAMAAAAvKgi2ACgQ
Op8ABQGwKhAgtgApPCoQPbYAKT0bHKIACyoQBhu2ACWwKhAGHLYAJbAAAAABAEEAAAAeAAcAAABW
AAoAVwAMAFkAEwBaABoAWwAfAFwAJwBfAAkASgBFAAEAQAAAAEIAAwAEAAAAHioQIrYAKTwqGwRg
tgAjTSwQIrYAKT4sHQRgtgAjsAAAAAEAQQAAABIABAAAAGUABwBmAA8AZwAWAGgACQBLAEwAAQBA
AAAAYQAFAAQAAAA1Kiu2ACI9HAKgAAUqsLsACVkqAxy2ACW3ACpOLSocK7YAK2AEYLYAI7YAElct
tgAUK7gAJ7AAAAABAEEAAAAaAAYAAABsAAYAbQALAG4ADQBwABsAcQAsAHIACQBNAE4AAQBAAAAA
SgACAAIAAAAeKr4GnwAMsgAsEi22AC6xuwAvWbcAMEwrKrYAMVexAAAAAQBBAAAAGgAGAAAAdgAG
AHcADgB4AA8AegAXAHsAHQB8AAEATwAAAAIAUA==

]]></code>

<post/>
<resources>
</resources>
</xcomponent>

[Xpipe-users] XComponent <parameters> working?

[Roger L. C. <cos...@mi...>]

I am trying to use the parameter element in xcomponents.  I have created
an xcomponent which changes the name of an element, where the name of
the element to be replaced and its replacement value are specified as a
parameter [see the xcomponent below].  The problem is that the
parameters don't seem to be getting to my xcomponent's code (a
stylesheet).  Am I doing something wrong, or is it simply that
parameters have not been implemented yet?

My second question is more general, on how parameters get delivered to
an xcomponent's code.  I assume that when the code is xslt the
parameters get delivered just as stylesheet parameters.  Right?  What if
the code is Java?  Do the parameters get delivered as parameters to the
main routine, i.e., 

public static void main(String[] args)

The parameters will be in the args array?

As I dig deeper I am getting more and more excited about this
technology.  This is the right approach I feel.  I wish that I had the
time to help implement the core pieces.  Timeliness is crucial, I
think.  /Roger

changeElementName.xco

<xcomponent>
<version>0.1</version>
<title>Change Element Name - XSLT</title>
<keywords>
	<keyword>XSLT</keyword>
	<keyword>Change Element Name</keyword>
</keywords>
<authorInfo>
    Roger L. Costello
</authorInfo>

<doc>
<h1>Change Element Name</h1>
<p>Change the name of an element</p>
</doc>

<parameters>
    <parameter
name="nameOfElementToChange">WorldFactbookReferenceDeskRequest</parameter>
    <parameter
name="newNameOfElement">WorldFactbookReferenceDeskRequestResults</parameter>
</parameters>

<unitTests>
	<test name ="First Test">
		<parameters>
                    <parameter
name="nameOfElementToChange">foo</parameter>
                    <parameter name="newNameOfElement">bar</parameter>
                </parameters>
		<pre/>
		<input href="#unitTestFile1"/>
		<output href="#unitTestFile2"/>
		<post/>
	</test>
</unitTests>

<pre/>
<code type="XSLT" encoding="PLAIN" extractFilename=""
CLASSPATH=""><![CDATA[
<!-- Change the name of an element -->
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                version="1.0">
 
    <xsl:output method="xml"/>
    <xsl:param name="nameOfElementToChange"/>
    <xsl:param name="newNameOfElement"/>

    <xsl:template match="*">
        <xsl:if test="name(.) != $nameOfElementToChange">
            <xsl:element name="{name(.)}">
                <xsl:for-each select="@*">
                    <xsl:attribute name="{name(.)}">
                        <xsl:value-of select="."/>
                    </xsl:attribute>
                </xsl:for-each>
                <xsl:apply-templates/>
            </xsl:element>
        </xsl:if>
        <xsl:if test="name(.) = $nameOfElementToChange">
            <xsl:element name="{$newNameOfElement}">
                <xsl:for-each select="@*">
                    <xsl:attribute name="{name(.)}">
                        <xsl:value-of select="."/>
                    </xsl:attribute>
                </xsl:for-each>
                <xsl:apply-templates/>
            </xsl:element>
        </xsl:if>
    </xsl:template>

</xsl:stylesheet>
]]>
</code>
<post/>

<resources>
<resource id = "unitTestFile1">
<![CDATA[
<?xml version="1.0"?>
<test isIt="true"><foo>Hello World</foo></test>
]]>
</resource>

<resource id = "unitTestFile2">
<![CDATA[
<?xml version="1.0"?>
<test isIt="true"><bar>Hello World</bar></test>
]]>
</resource>
</resources>

</xcomponent>

Re: [Xpipe-users] Meaning of the command line parameters of InstallXPipe and ExecuteXPipe? Finding xcomponents?

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

At 10:16 23/02/2002 -0500, Roger L. Costello wrote:
>I have 2 questions:
>
>1. I would like to understand better the meaning of the command line
>parameters to InstallXPipe.py and ExecuteXPipe.py.
>
>In the example described in the README file it gives this example:
>
>jython InstallXPipe.py xp0.xpi testdir
>
>I interpret this command as: "Install the XPipe, xp0.xpi, that is in the
>folder, testdir". Is this a correct interpretation?

The correct interpretation is "install the pipe housed in xp0.xpi into
the directory rooted at testdir".

For executing an XPipe the README file gives this example:

>jython ExecuteXPipe.py xp0.xpi testdir in.xml out.xml log.log


The README says
  jython ExecuteXPipe.py testdir in.xml out.xml log.log

There is no xp0.xpi in the command.

Does this clear it up?


2. In the XPipe, xp0.xpi, it references 3 xcomponents:

><xcomponents>
>         <xcomponentRef href = "xc1.xco">
>                 <doc><p>A null transformation in Java</p></doc>
>                 <parameters></parameters>
>         </xcomponentRef>
>
>         <xcomponentRef href = "xc2.xco">
>                 <doc><p>A null transformation in XSLT</p></doc>
>                 <parameters></parameters>
>         </xcomponentRef>
>
>         <xcomponentRef href = "xc3.xco">
>                 <doc><p>A null transformation in Jython</p></doc>
>                 <parameters></parameters>
>         </xcomponentRef>
>
></xcomponents>
>
>Note the href to each xcomponent, for example: href = "xc1.xco".  When
>the XPipe is Installed:
>
>jython InstallXPipe.py xp0.xpi testdir
>
>the xcomponents are somehow obtained.  This href seems to indicate the
>the xcomponents are in the current folder.  In fact, they are in a
>different folder (../xcomponents).  Shouldn't the href be something like
>this: href="../xcomponents/xc1.xco"?  How did InstallXPipe know how to
>fetch the xcomponents given these hrefs?

The idea is that the hrefs be URIs. In this release XPIPE_HOME environment
variable is used to specify a home directory for XPIPE. The software looks
in this directory + in an xcomponents sub-directory to find
components.


>   It seems that there is some
>implicit understanding by InstallXPipe that the xcomponents will always
>be in the xcomponents folder.


>  Is that true?

Yes.

>   Isn't that bad?

Yes and no. In an ideal world all filesystems would have HTTP interfaces
and we could just use URLs without further thought. We are not
there yet though so XPIPE_HOME trickery is. I think, a worthwhile
feature for now.

regards,
Sean