Free sax software for linux

XML::SAX is a simple API for XML.

SYNOPSIS

use XML::SAX;

# get a list of known parsers
my $parsers = XML::SAX->parsers();

# add/update a parser
XML::SAX->add_parser(q(XML::SAX::PurePerl));

# remove parser
XML::SAX->remove_parser(q(XML::SAX::Foodelberry));

# save parsers
XML::SAX->save_parsers();

XML::SAX is a SAX parser access API for Perl. It includes classes and APIs required for implementing SAX drivers, along with a factory class for returning any SAX parser installed on the users system.

Pod::SAX is a SAX parser for Pod.

SYNOPSIS

my $h = XML::SAX::Writer->new();
my $p = Pod::SAX->new( Handler => $h );
$p->parse_uri(perlpodspec.pod);

Very simply, this module parses POD (or perl) files and turns the Plain Old Documentation into SAX events (which often youll use to turn into XML, but there are other uses as well).

The aim of this module is not round-tripping, so some things may be lost in the conversion. The aim is to be as standards compliant as possible, while giving you very simple access to the data.

The main motivation for this module though was simple standards compliance - all the Pod parsers out there seem to have their own unique way of doing things, and so my aim was to unify that and allow the flexibility that SAX gives me at the same time.

For an introduction to SAX, please read XML::SAX::Intro.

One very important point to note is that just because this is a SAX module it doesnt mandate that the results are XML. You could just as easily use this module to extract all filenames from a POD file, or extract custom =for/=begin sections. And because it uses standardised interfaces this is a lot simpler than working with any other POD parser out there, and the knowledge is transferrable.

GooeySAX is a cross-platform tool that wraps an underlying SAX parser (Apache Xerces, to be exact) in a Java Swing interface. You can use GooeySAX to parse XML documents on your local file system or across the network to determine their Well-Formedness.

With the optional Validity setting enabled, you may also validate your document against a DTD. New in version 2.0 -- W3C XML Schema validation support as well!
GooeySAX is the perfect tool for the web author who cares!

Checking your XHTML documents validity either locally or remotely is a snap, and GooeySAXs detailed error messages let you know about those embarassing validation errors immediately.

GooeySAX is easy to use... select an XML document for parsing in one of three ways:

Type a URL into GooeySAXs System ID location bar.
Select File menu -> Browse... to browse for a file on your local system.
Drag a file from you local system onto the GooeySAX window.

Then select the Validate checkbox if you wish to validate your document against a DTD. How do you select the DTD against which to validate? Easy! Simply declare the DTD in your documents Doctype Declaration or declare the XML Schema instance as normal... GooeySAX will figure out the rest!

Finally, click the Parse button and watch the results appear.

XML::SAX::Base is a base Perl class with SAX Drivers and Filters.

SYNOPSIS

package MyFilter;
use XML::SAX::Base;
@ISA = (XML::SAX::Base);

This module has a very simple task - to be a base class for PerlSAX drivers and filters. Its default behaviour is to pass the input directly to the output unchanged. It can be useful to use this module as a base class so you dont have to, for example, implement the characters() callback.

The main advantages that it provides are easy dispatching of events the right way (ie it takes care for you of checking that the handler has implemented that method, or has defined an AUTOLOAD), and the guarantee that filters will pass along events that they arent implementing to handlers downstream that might nevertheless be interested in them.

WRITING SAX DRIVERS AND FILTERS

Writing SAX Filters is tremendously easy: all you need to do is inherit from this module, and define the events you want to handle. A more detailed explanation can be found at http://www.xml.com/pub/a/2001/10/10/sax-filters.html.
Writing Drivers is equally simple. The one thing you need to pay attention to is NOT to call events yourself (this applies to Filters as well). For instance:
package MyFilter;
use base qw(XML::SAX::Base);

sub start_element {
my $self = shift;
my $data = shift;
# do something
$self->{Handler}->start_element($data); # BAD
}

The above example works well as precisely that: an example. But it has several faults: 1) it doesnt test to see whether the handler defines start_element. Perhaps it doesnt want to see that event, in which case you shouldnt throw it (otherwise itll die). 2) it doesnt check ContentHandler and then Handler (ie it doesnt look to see that the user hasnt requested events on a specific handler, and if not on the default one), 3) if it did check all that, not only would the code be cumbersome (see this modules source to get an idea) but it would also probably have to check for a DocumentHandler (in case this were SAX1) and for AUTOLOADs potentially defined in all these packages. As you can tell, that would be fairly painful. Instead of going through that, simply remember to use code similar to the following instead:

package MyFilter;
use base qw(XML::SAX::Base);

sub start_element {
my $self = shift;
my $data = shift;
# do something to filter
$self->SUPER::start_element($data); # GOOD (and easy) !
}

This way, once youve done your job you hand the ball back to XML::SAX::Base and it takes care of all those problems for you!

Note that the above example doesnt apply to filters only, drivers will benefit from the exact same feature.

XML::SAX::Machine is a Perl module that can manage a collection of SAX processors.

SYNOPSIS

## Note: See XML::SAX::Pipeline and XML::SAX::Machines first,
## this is the gory, detailed interface.

use My::SAX::Machines qw( Machine );
use My::SAX::Filter2;
use My::SAX::Filter3;

my $filter3 = My::SAX::Filter3->new;

## A simple pipeline. My::SAX::Filter1 will be autoloaded.
my $m = Machine(
#
# Name => Class/object => handler(s)
#
[ Intake => "My::SAX::Filter1" => "B" ],
[ B => My::SAX::Filter2->new() => "C" ],
[ C => $filter3 => "D" ],
[ D => *STDOUT ],
);

## A parser will be created unless My::SAX::Filter1 can parse_file
$m->parse_file( "foo.revml" );

my $m = Machine(
[ Intake => "My::SAX::Filter1" => qw( Tee ) ],
[ Tee => "XML::Filter::SAXT" => qw( Foo Bar ) ],
[ Foo => "My::SAX::Filter2" => qw( Out1 ) ],
[ Out1 => $log ],
[ Bar => "My::SAX::Filter3" => qw( Exhaust ) ],
);

WARNING: This API is alpha!!! It will be changing.

A generic SAX machine (an instance of XML::SAX::Machine) is a container of SAX processors (referred to as "parts") connected in arbitrary ways.

Each parameter to Machine() (or XML::SAX::Machine-new()>) represents one top level part of the machine. Each part has a name, a processor, and one or more handlers (usually specified by name, as shown in the SYNOPSIS).

Since SAX machines may be passed in as single top level parts, you can also create nested, complex machines ($filter3 in the SYNOPSIS could be a Pipeline, for example).

A SAX machines can act as a normal SAX processors by connecting them to other SAX processors:

my $w = My::Writer->new();
my $m = Machine( ...., { Handler => $w } );
my $g = My::Parser->new( Handler => $w );

iCal::Parser::SAX is a Perl module to generate SAX events from an iCalendar.

SYNOPSIS

use iCal::Parser::SAX;
my $parser=iCal::Parser::SAX->new(Handler=>SAXHandler,%args);
$parser->parse_uri($file);
$parser->parse_uris(@files);

This module uses iCal::Parser to generates SAX events for the calendar contents.

The xml document generated is designed for creating monthly calendars with weeks beginning on monday (e.g., by passing the output through an xsl styleheet).

The basic structure of the generated document (if output through a simple output handler like XML::SAX::Writer), is as follows:

< ical>
< calendars>
< calendar id="cal-id" index="n" name="..." description="..."/>
< /calendars>
< events>
< year year="YYYY">
< month month="[1-12]">
< week week="n">
< day date="YYYY-MM-DD">
< event uid="event-id" idref="cal-id" [all-day="1"]>
< !-- ... -->
< /event>
< /day>
< /week>
< /month>
< /events>
< todos>
< todo idref="cal-id" uid="...">
< !--- ... -->
< /todo>
< /todos>
< /ical>

Along with basics, such as converting calendar attributes to lowercase elements (e.g., a DTSTART attribute in the input would generate a sax event like element({Name=dtstart})>), a number of other processes occur:

day elements are are generated for each date within the months from the first month in the input to the last, even if there are no calendar events on that day. This guarantees a complete calendar month for further processing. If there is an overlap between two or more events, the attribute conflict, containing the number of concurrent overlaps, is added to the element.

If the beginning or end of the month does not start on a monday, or end on a sunday, the days from the previous (next) month month are duplicated within the first (last) week of the current month, including duplicate copies of any calendar events occuring on those days. This allows for displaying a monthly calendar the same way a program such as Apples iCal would, with calendar events showing up if they fall within the overlapping days in the first or last week of a monthly calendar.

XML::SAX::ByRecord can record oriented processing of (data) documents.
SYNOPSIS
use XML::SAX::Machines qw( ByRecord ) ;
my $m = ByRecord(
"My::RecordFilter1",
"My::RecordFilter2",
...
{
Handler => $h, ## optional
}
);
$m->parse_uri( "foo.xml" );
XML::SAX::ByRecord is a SAX machine that treats a document as a series of records. Everything before and after the records is emitted as-is while the records are excerpted in to little mini-documents and run one at a time through the filter pipeline contained in ByRecord.
The output is a document that has the same exact things before, after, and between the records that the input document did, but which has run each record through a filter. So if a document has 10 records in it, the per-record filter pipeline will see 10 sets of ( start_document, body of record, end_document ) events. An example is below.
This has several use cases:
- Big, record oriented documents
Big documents can be treated a record at a time with various DOM oriented processors like XML::Filter::XSLT.
- Streaming XML
Small sections of an XML stream can be run through a document processor without holding up the stream.
- Record oriented style sheets / processors
Sometimes its just plain easier to write a style sheet or - SAX filter that applies to a single record at at time, rather than having to run through a series of records.

Mac::PropertyList::SAX is a Perl module to work with Mac plists at a low level (with real XML parsers).

Mac::PropertyList is useful, but very slow on large files because it does the parsing by itself, intead of handing off the actual XML parsing to a dedicated parser. This module uses XML::SAX::ParserFactory to select a parser capable of doing the heavy lifting, reducing parsing time on large files by up to 97%. This is especially useful for iTunes library plists which may be megabytes in size and contain thousands of entries in dozens of dictionaries.

This module does not, however, replace Mac::PropertyList; in fact, it depends on it for several package definitions and the plist creation routines.

Be aware that performance will depend largely on the parser that XML::SAX::ParserFactory selects for you; if you have not installed XML::SAX::Expat or another fast parser, the default XML::SAX::PurePerl parser will be used; this will probably give worse performance than Mac::PropertyList, so ensure that a fast parser is being used before you complain to me about performance :-). See XML::SAX::ParserFactory for information on how to set which parser is used.