Lists Home |
Date Index |
On Apr 9, 2005, at 3:45 AM, Erik Bruchez wrote:
> Alex Milowski wrote:
> > This smallx technology was designed to process XML infosets.
> So does the XPL engine within OPS. It is in fact the kernel of OPS,
> and it's sole purpose is to process XML infosets.
> > The convergence on XML pipelines between Orbeon and smallx is just
> > validation that it is the right idea for XML processing. In fact,
> > there are many other projects supporting XML pipelining technology
> > (e.g. Cocoon, SXPipe, Markup Technology, etc.).
> None of them being as good as XPL, in all modesty ;-)
> > In addition, my essential requirement is that it support streaming
> > of infosets.
> The OPS XPL engine is based on SAX. I don't know if you have more in
> mind regarding streaming.
In smallx you stream info items--not SAX. As such, when you receive
a start tag you get the name, attributes, and in-scope namespaces.
In SAX, those are separate callbacks and implementing against that
is much harder.
From an implementation perspective, I do not want to write components
based on SAX. It is too cumbersome.
> > The Orbeon Presentation Server project/product is really good
> > technology but I'm not certain that the XML Pipelining technology is
> > separable at the current time.
> It is separable - and separate. For example, you can run raw pipelines
> from the command line. The only misssing thing at this point is a
> separate JAR file, but that's purely a packaging question.
That's good to hear.
> > I would say, convergence on *one* XML pipelining specification
> > language would be a really good thing!
> Then I invite you to have a look at the XPL draft spec:
The XPL specification for pipelines is very different the smallx
pipeline specification. XPL and SXPipe share a common "heritage" or
"architecture" of the Sun Microsystems note on XML Pipelines. That is,
the conceptual mode of the pipeline language as a sequence of
processors is the same.
smallx XML pipelines follow the idea the pipeline is a specification
of a transformation and the steps are like XSLT extension elements.
step in the pipeline is really an extension element that has
its own syntax. That way you can embed specialized syntax or other
steps without external files. You can also embed steps that have no
specification other than the element syntax you are using.
For example, XSLT can be used in several ways:
In this example, there are two XSLT steps where the second has the
stylesheet embedded. But you can also have the step:
which operates on any [c:]apply-xslt elements it finds. That allows
dynamic creation of transformations, binding of parameters, etc.
Another example is the regular expression step:
<p:regex select="person" pattern="^(\S+)\s+(\S+)">
where each 'person' element has the regular expression "^(\S+)\s+(\S)"
run on it to produce two new child elements 'firstname' and 'lastname'.
The [p:]template element is just a shorthand for XSLT.
Further, if you want to write a custom step, you can declare the
extension namespace and embed your own syntax with your own schema
for that element. In this way, the pipeline language is extensible.
Of course, someone has to write the supporting code, but I've tried
to make that easy by the APIs for the infoset and bootstrapping
mechanism to get the syntax into the compiler. The implementation
has a registry which is an XML document. You just have to modify that
to get your step into the language.
-- Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of
inflexions, i.e. to the degree of analysis effected by the language
Bertrand Russell in a footnote of Principles of Mathematics