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