Re: [xsl] XMLPipe model: should we change the name?

Subject: Re: [xsl] XMLPipe model: should we change the name?
From: Michael Pediaditakis <mp49@xxxxxxxxx>
Date: Sat, 22 Feb 2003 17:47:18 +0000
Mike Brown wrote:

Michael Pediaditakis wrote:


We are in the process of finishing the implementation of
a model (in Java) that realises a number of ideas on
transformation pipelining, heterogeneous documents
combination and handling and a way to semi-automatically
produce the correct combination of transformations for a
specific application profile.

Now, the core aspect of the whole architecture is the
pipelining of transformations (mainly XSL-T) for the
XML documents... And thus, the original name that I thought
to give to the whole model and the implementation is
"XMLPipe".



TransformationPipe? (t12nPipe?) XSLTPipe? Perhaps something incorporating the word "flow" or "chain"?

Hmm... thanx.. t12nPipe (that's amazing).
The problem is that TransformationPipe is like having transformations flow
through the pipes (we could say TransformationPipeline.. which is too long though).





XML* names should be reserved for W3C products and recommendations


Too late. Although in XML documents, yes, they reserve the xml* names :)


In that case I could keep the XMLPipe name and avoid changing vast amounts of (crapy Java) code!



So, my question is: Do you think that I should change the
name before we make a public release of the model and implementation?



I'm surprised you didn't lock yourself into a name when you were making the prototype, like the rest of us do :) Having the chance to change the name of your product just before release, and to put some serious thought behind it is a luxury many companies don't have.

Well, the difference is that I'm not a company ...a poor research student instead.. and I used the original XMLPipe
name when I created a simple pipelining program to help me with some experiments.. and it was interesting, and thus
I created a generic model for pipelines, device neutral handling etc etc which was based on the original XMLPipe
implementation. So there was never a formal name anyway!



One thing that we noticed when implementing stylesheet chaining/pipelining/ whatever in 4Suite (see, I can advertise, too) is the problem of what to do with external stylesheet parameters. Say you want to pass the output of stylesheet 1 to stylesheet 2, and stylesheet 2 needs some top-level parameters passed in. For now we just don't do anything; only the first stylesheet in the chain gets that privilege. So I'm curious... what does your system do in this regard? Or if you prefer not to divulge, what do people think a system *should* do?



My approach is to introduce a generic "context" information which is shared between different transformations.
A part of this context is the "pipeline context" which can be used to pass parameters to the stylesheets either
from the user or from stylehseets earlier in the pipeline.


This becomes quite a problem when the architecture is not XSLT specific, where the "general purpose" context
information has to be tranformed to an XSL-T form. I'm currently between two basic approaches:
- Either pass it as XSLT variable information (i.e. normal XSLT user parameters)
- Or pass it as part of the document
(the 2nd approach seems more interesting because it provides a unified framework for
bi-directional communication - so that the stylesheet can also modify the context)


When the implementation is finished and after I try both of the approaches I'll post the results!

Thanks for the comments,
Mike.



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


Current Thread