xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james_strac...@yahoo.co.uk>
Subject Re: [Announce] CyberNeko Tools for XNI 2002.06.18 Available
Date Wed, 19 Jun 2002 09:23:25 GMT
Hi Andy

The CyberNeko Tools for XNI and the Style Processor looks very interesting
stuff indeed!

One question though; your Pipeline processor looks to be based on the W3C
DOM (at least from the documentation, I've not surfed the code yet). Did you
consider making a SAX or XNI based pipeline engine? If so what were the
reasons for having a DOM based pipeline?

Incidentally I'm working on a Java and XML based processing engine called


Jelly is a lot like JSP custom tags, where a fully qualified name can be
matched to a 'Tag' which performs some action. Jelly is a bit like Ant with
pluggable expresssion languages like XPath and Velocity (Jexl is the core
expression language that looks a whole lot like Velocity and is a super set
of the expression language in JSTL and JSP 2.0). But also Jelly is like
Cocoon, its is based on an XML pipeline architecture too - which currently
is based on SAX. So a Jelly script is XML and the output is SAX events and
each Jelly Tag can consume, filter, transform or emit SAX events as well as
working with variables like Ant/JSP/Velocity.

Jelly is totally modular and can be extended with custom tag libraries.
There's a whole host of existing tag libraries for it, such as a subset of
the JSTL tags for working with beans, XML, XPath, XSLT and SQL. There's a
tag library for working with Ant tasks. Its on the to do list to implement
an MSV tag library for validating SAX events (the body of a tag) against an
arbitrary schema language (DTD, XML Schema, RelaxNG, TREX or Relax), along
with implementing a STX tag library for transforming SAX events.

Now it could well be that we could use the XNI Tools inside Jelly, by
binding your pipeline processors to qualified names (jelly tags). e.g.

<!-- ported the 2nd example from your docs -->
<output:html file="index.html">
    <xslt:transform xslt="foo.xsl">
        <parse:xml uri="index.xml">

Incidentally the above could be implemented using a SAX or DOM pipeline.

Now this might not seem too useful at first, its just another XML
representation for using Cybernecko processors, but it means we can then mix
and match other tag libraries into the script too; like iterating and
conditional branching using various expression languages (Jexl, XPath,
Beanshell, JavaScript etc), iterating over files using Ant's <fileset>'s,
executing Ant tasks inside the script, invoking SOAP services, using tag
macros, performing SQL or working with beans in a Velocity way etc.

Also we could investigate mixing and matching SAX/XNI based and DOM based
pipeline mechanisms together in one script; turning SAX/XNI events into DOM
objects when it makes sense and leaving things as straight SAX if we can

Thoughts? (I hope some of this made some sense ;-)

----- Original Message -----
From: "Andy Clark" <andyc@apache.org>
To: <general@xml.apache.org>
Cc: <xerces-j-user@xml.apache.org>; <xerces-j-dev@xml.apache.org>
Sent: Tuesday, June 18, 2002 1:15 PM
Subject: [Announce] CyberNeko Tools for XNI 2002.06.18 Available

> When I made the announcement a few days ago about the
> first version of the CyberNeko Tools for XNI, I was
> busy working on another tool. At the time, it wasn't
> quite ready for release so I pushed out the first
> collection of tools without it. But now it's ready! :)
> I am pleased to announce the 2002.06.18 release of
> NekoXNI! This release adds a new tool to the lineup:
> the CyberNeko Style Processor, version 0.1.
> NekoStyle is an XML batch processing framework that
> is similar to the StyleBook tool we've been using for
> several years to generate documentation of XML projects
> here at Apache.
> Why have I chosen to create yet another XML batch
> processing framework? Because I wasn't happy with the
> other ones. Because I like doing things *my* way.
> Because I could. Because we just don't have enough of
> them. ;) Because of a million reasons... Take your pick.
> But before you decide whether it was worthwhile to
> write in the first place, check out the web page[1],
> download the code[2], and try it out for yourself.
> You may find that you like it! Or not. Either way,
> it works extremely well for what I need to do. :)
> NekoStyle offers the following features:
>    * simple, flexible, and extensible framework for
>      automating XML processing
>    * JAXP/TrAX compliant
>    * parses HTML documents (using NekoHTML) as well
>      as XML documents
>    * dynamic pipelines
>    * an Ant task for executing within build scripts
>    * small size (the Jar is only 25K!)
> and perhaps the most important is:
> One of the primary reasons I delayed the initial
> release was so that I could write more documentation
> about how it works. I hate writing docs as much as
> the next person but I knew it was important for
> people to understand the framework.
> In fact, the HTML documentation included with NekoStyle
> is actually generated *by* the NekoStyle processor at
> build time. So this is a good way to learn how the
> system works in practice.
> <aside>
> Most of the content is written in DocBook and then
> transformed to the HTML output. However, there are
> some files that are written using custom DTDs so that
> they can keep the semantic meaning behind the data.
> These files (e.g. the change log) are first converted
> to DocBook and then to HTML.
> (This is one of my first attempts at using DocBook so
> you'll have to excuse me if I used it incorrectly in
> certain places. That grammar is HUGE! ;)
> </aside>
> The real reason that I wrote NekoStyle was that I
> needed specific features for other things that I'm
> working on. So that's what I designed it for. There
> are a few limitations and things I want to improve
> but I think it's a nice little system for performing
> XML processing. And I already have plans for features
> to add in subsequent versions.
> The most important feature I want to add is a
> template processor that people can use to write the
> output HTML. This would allow them to change the
> design of the output without needing to edit XSLT
> stylesheets. *And*, using NekoHTML, these templates
> can be written in standard, "dirty" HTML much like
> the templating functionality in other systems (e.g.
> PostNuke, etc). This would alleviate a lot of the
> trouble in maintaining documentation and adapting
> the old docs to fit new requirements.
> Anyway, if you need a small library to automate
> batch XML processing, then NekoStyle may be what you
> need. So check it out and let me know what you think.
> You can also download all of the NekoXNI tools in a
> single package[3] if you don't already have NekoHTML
> or NekoDTD.
> Enjoy!
> [1] http://www.apache.org/~andyc/neko/doc/style/
> [2] http://www.apache.org/~andyc/neko/nekostyle-0.1.zip
>      http://www.apache.org/~andyc/neko/nekostyle-0.1.tar.gz
> [3] http://www.apache.org/~andyc/neko/nekoxni-2002.06.18.zip
>      http://www.apache.org/~andyc/neko/nekoxni-2002.06.18.tar.gz
> --
> Andy Clark * andyc@apache.org
> ---------------------------------------------------------------------
> In case of troubles, e-mail:     webmaster@xml.apache.org
> To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
> For additional commands, e-mail: general-help@xml.apache.org

Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

View raw message