OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] [ANN] smallx XML Infoset and Pipeline Released (Open Sourc

[ Lists Home | Date Index | Thread 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:
>
>   http://www.orbeon.com/ops/2005/xpl/

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 
orchestrated
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.  
Each
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:

  <p:pipe name="example" 
xmlns:p="urn:publicid:IDN+smallx.com:pipeline:1.0";
          xmlns:xsl="http://www.w3.org/1999/XSL/Transform";>
    <p:xslt src="mytransform.xsl"/>
    <p:xslt>
       <p:parameter name="color">red</p:parameter>
       <xsl:transform version="1.0">
           <xsl:template match="/">...</xsl:template>
            etc.
       </xsl:transform>
    </p:xslt>
  </p:pipe>

In this example, there are two XSLT steps where the second has the
stylesheet embedded.  But you can also have the step:

<p:xslt/>

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+)">
<p:template>
<xsl:param name="group-1"/>
<xsl:param name="group-2"/>
<firstname><xsl:value-of select="$group-1"/></firstname>
<lastname><xsl:value-of select="$group-2"/></groupname>
</p:template>
</p:regex>

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 
the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS