You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xerces.apache.org by Andy Clark <an...@apache.org> on 2002/06/18 14:15:29 UTC
[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:
* DOCUMENTATION! :)
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
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org
Re: [Announce] CyberNeko Tools for XNI 2002.06.18 Available
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Andy Clark" <an...@apache.org>
> James Strachan wrote:
> > BTW it wasn't my intention to suggest Jelly was in any way competitive
> > technology, more that Jelly could be an alternative runtime engine for
your
> > pipeline processors; that if more power and complexity is required (such
as
> > working with beans or web services) then Jelly + CyberNeko could well be
> > kinda cool stuff.
>
> Yep. I've been impressed with your work on DOM4J and
> from what I've seen of Jelly, it's equally impressive.
Thanks Andy.
> Right now I'm working on a bunch of things at the same
> time so I don't know if I'll be able to take a good
> look at it in the short term. However, I would like
> to look at more in depth some time.
No problem.
> Keep up the good work! :)
And keep up the good work on your various CyberNeko projects, they're
interesting stuff indeed!
James
_________________________________________________________
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
Re: [Announce] CyberNeko Tools for XNI 2002.06.18 Available
Posted by Andy Clark <an...@apache.org>.
James Strachan wrote:
> BTW it wasn't my intention to suggest Jelly was in any way competitive
> technology, more that Jelly could be an alternative runtime engine for your
> pipeline processors; that if more power and complexity is required (such as
> working with beans or web services) then Jelly + CyberNeko could well be
> kinda cool stuff.
Yep. I've been impressed with your work on DOM4J and
from what I've seen of Jelly, it's equally impressive.
Right now I'm working on a bunch of things at the same
time so I don't know if I'll be able to take a good
look at it in the short term. However, I would like
to look at more in depth some time.
Keep up the good work! :)
--
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
Re: [Announce] CyberNeko Tools for XNI 2002.06.18 Available
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Andy Clark" <an...@apache.org>
> James Strachan wrote:
> > 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?
>
> Yeah, I knew people would ask about that. I expect
> documents are going to be used multiple times so I
> figured it would be easiest to base the system on a
> tree API.
OK.
> And since the DOM is the standard tree
> API, it was the natural choice. (I know you would
> disagree and prefer to use DOM4J, though. :)
of course ;-)
Actually Jelly uses Jaxen for its XPath stuff so it can work with all 4
DOM-ish APIs, W3C DOM, dom4j, EXML and JDOM.
> Depending on what I need to do with the tool, I may
> end up adding additional ways to pass information
> from stage to stage. Adding SAX would be a natural
> choice, of course. However, performance is not one
> of my major priorities and adding other APIs would
> just increase the size of the code which IS one of
> my major priorities. Right now the Jar is 25K.
Agreed.
> > Incidentally I'm working on a Java and XML based processing engine
called
> > Jelly...
>
> From what I can tell from the docs, it looks quite
> impressive. I'll definitely look into it more when
> I get a chance. However, it looks a lot bigger than
> what I need to do. The Jelly jar is 122K and it has
> a long line of requirements. (Excluding the XML
> parser and XSLT processor, what is the total size
> of required Jar files to run a typical Jelly
> script?)
You're right, I think Jelly is always going to be quite a bit bigger than
your pipeline tools. Though I do think your pipeline stuff would work very
nicely with Jelly if folks wanted more complex or powerful kinds of
pipelines like to mix some DOM-based XML pipeline processors with working
with beans, web services or SQL or whatnot.
Incidentally one of the reasons for the current Jelly jar being so large and
having so many dependencies is a current limitation of the Maven build
system. Jelly is really quite modular - the core is fairly small, then
different expression languages and tag libraries can be plugged in based on
what the user needs. Right now the whole thing is built in one bundle which
makes Jelly and its dependencies look bigger than it really is. Mostly
Jelly's core just depends on an XML parser and a few small jars from Jakarta
Commons (beanutils, collecitons, logging, jexl). Its other tag libraries
that bring in new dependencies.
> > 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.
>
> Cool.
BTW it wasn't my intention to suggest Jelly was in any way competitive
technology, more that Jelly could be an alternative runtime engine for your
pipeline processors; that if more power and complexity is required (such as
working with beans or web services) then Jelly + CyberNeko could well be
kinda cool stuff.
> > Thoughts? (I hope some of this made some sense ;-)
>
> I'll have to digest it all first. :)
:-)
And me of your pipeline stuff too ;-)
James
_________________________________________________________
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
Re: [Announce] CyberNeko Tools for XNI 2002.06.18 Available
Posted by Andy Clark <an...@apache.org>.
James Strachan wrote:
> 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?
Yeah, I knew people would ask about that. I expect
documents are going to be used multiple times so I
figured it would be easiest to base the system on a
tree API. And since the DOM is the standard tree
API, it was the natural choice. (I know you would
disagree and prefer to use DOM4J, though. :)
Depending on what I need to do with the tool, I may
end up adding additional ways to pass information
from stage to stage. Adding SAX would be a natural
choice, of course. However, performance is not one
of my major priorities and adding other APIs would
just increase the size of the code which IS one of
my major priorities. Right now the Jar is 25K.
> Incidentally I'm working on a Java and XML based processing engine called
> Jelly...
From what I can tell from the docs, it looks quite
impressive. I'll definitely look into it more when
I get a chance. However, it looks a lot bigger than
what I need to do. The Jelly jar is 122K and it has
a long line of requirements. (Excluding the XML
parser and XSLT processor, what is the total size
of required Jar files to run a typical Jelly
script?)
> 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.
Cool.
> Thoughts? (I hope some of this made some sense ;-)
I'll have to digest it all first. :)
--
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
Re: [Announce] CyberNeko Tools for XNI 2002.06.18 Available
Posted by James Strachan <ja...@yahoo.co.uk>.
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...
<quickIntro>
http://jakarta.apache.org/commons/sandbox/jelly/
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.
</quickIntro>
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">
</xslt:transform>
</output:html>
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
too.
Thoughts? (I hope some of this made some sense ;-)
James
----- Original Message -----
From: "Andy Clark" <an...@apache.org>
To: <ge...@xml.apache.org>
Cc: <xe...@xml.apache.org>; <xe...@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:
>
> * DOCUMENTATION! :)
>
> 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
RE: Suppressing DTD Defaults Processing with Xerces/JAXP interface
Posted by Rick Bullotta <ri...@lighthammer.com>.
Got an answer:
Add a dummy EntityResolver that bypasses DTD processing as in:
private class DummyResolver implements EntityResolver {
public InputSource resolveEntity(String publicID, String systemID) throws
IOException, SAXException {
return( new InputSource(new StringReader("")));
}
}
Then, set the DocumentBuilder object's resolver to this one instead, as in:
dBuilder.setEntityResolver(new DummyResolver());
Voila! Success!
Rick Bullotta
CTO
Lighthammer Software (www.lighthammer.com)
-----Original Message-----
From: Rick Bullotta [mailto:rick.bullotta@lighthammer.com]
Sent: Tuesday, June 18, 2002 12:13 PM
To: xerces-j-user@xml.apache.org
Cc: xerces-j-dev@xml.apache.org
Subject: Suppressing DTD Defaults Processing with Xerces/JAXP interface
Given a document:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE iChart SYSTEM "http://localhost/Illuminator/DTD/iChart.dtd">
<iChart SaveDate="06/18/2002 11:39:06" Version="9.0"
ChartBorderColor="#FFFF00" MainBorderColor="#FF0000"/>
...and the following code:
DocumentBuilderFactory dFactory = DocumentBuilderFactory.newInstance();
dFactory.setValidating(false);
dFactory.setExpandEntityReferences(false);
DocumentBuilder dBuilder = dFactory.newDocumentBuilder();
Document doc = dBuilder.parse(iStrm);
...I would expect that the DTD not be processed. However, there are
defaults defined in the DTD that are included in the resultant DOM.
How can this be suppressed with Xerces?
We are running Xerces 1.4.4, because of issues with Xalan compatibility.
Rick Bullotta
CTO
Lighthammer Software (www.lighthammer.com)
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
RE: Suppressing DTD Defaults Processing with Xerces/JAXP interface
Posted by Rick Bullotta <ri...@lighthammer.com>.
Got an answer:
Add a dummy EntityResolver that bypasses DTD processing as in:
private class DummyResolver implements EntityResolver {
public InputSource resolveEntity(String publicID, String systemID) throws
IOException, SAXException {
return( new InputSource(new StringReader("")));
}
}
Then, set the DocumentBuilder object's resolver to this one instead, as in:
dBuilder.setEntityResolver(new DummyResolver());
Voila! Success!
Rick Bullotta
CTO
Lighthammer Software (www.lighthammer.com)
-----Original Message-----
From: Rick Bullotta [mailto:rick.bullotta@lighthammer.com]
Sent: Tuesday, June 18, 2002 12:13 PM
To: xerces-j-user@xml.apache.org
Cc: xerces-j-dev@xml.apache.org
Subject: Suppressing DTD Defaults Processing with Xerces/JAXP interface
Given a document:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE iChart SYSTEM "http://localhost/Illuminator/DTD/iChart.dtd">
<iChart SaveDate="06/18/2002 11:39:06" Version="9.0"
ChartBorderColor="#FFFF00" MainBorderColor="#FF0000"/>
...and the following code:
DocumentBuilderFactory dFactory = DocumentBuilderFactory.newInstance();
dFactory.setValidating(false);
dFactory.setExpandEntityReferences(false);
DocumentBuilder dBuilder = dFactory.newDocumentBuilder();
Document doc = dBuilder.parse(iStrm);
...I would expect that the DTD not be processed. However, there are
defaults defined in the DTD that are included in the resultant DOM.
How can this be suppressed with Xerces?
We are running Xerces 1.4.4, because of issues with Xalan compatibility.
Rick Bullotta
CTO
Lighthammer Software (www.lighthammer.com)
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org
Suppressing DTD Defaults Processing with Xerces/JAXP interface
Posted by Rick Bullotta <ri...@lighthammer.com>.
Given a document:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE iChart SYSTEM "http://localhost/Illuminator/DTD/iChart.dtd">
<iChart SaveDate="06/18/2002 11:39:06" Version="9.0"
ChartBorderColor="#FFFF00" MainBorderColor="#FF0000"/>
...and the following code:
DocumentBuilderFactory dFactory = DocumentBuilderFactory.newInstance();
dFactory.setValidating(false);
dFactory.setExpandEntityReferences(false);
DocumentBuilder dBuilder = dFactory.newDocumentBuilder();
Document doc = dBuilder.parse(iStrm);
...I would expect that the DTD not be processed. However, there are
defaults defined in the DTD that are included in the resultant DOM.
How can this be suppressed with Xerces?
We are running Xerces 1.4.4, because of issues with Xalan compatibility.
Rick Bullotta
CTO
Lighthammer Software (www.lighthammer.com)
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org