3.1.11 (2019-06-25)

Bug Fixes

Performance Improvements

3.1.10 (2019-06-11)

Performance Improvements

3.1.9 (2019-02-25)

Bug Fixes

3.1.8 (2019-02-25)

3.1.7 (2019-02-22)

Bug Fixes

3.1.6 (2019-01-17)

Bug Fixes

3.1.5 (2019-01-08)

Bug Fixes

3.1.4 (2018-12-03)

Bug Fixes

3.1.3 (2018-10-01)

Bug Fixes

Performance Improvements

3.1.2 (2018-08-31)

Bug Fixes

3.1.1 (2018-08-29)

Bug Fixes

3.1.0 (2018-08-28)

Bug Fixes

Performance Improvements

3.0.0 (2018-08-21)

Features

BREAKING CHANGES

This commit makes it so that xmlns is not reported as having a prefix of "" and a local name of "xmlns". This accords with how people interpret attribute names like foo, bar, moo which all have no prefix and a local name.

Code that deals with namespace bindings or cares about xmlns probably needs to be changed.

2.2.1 (2018-08-20)

Bug Fixes

2.2.0 (2018-08-20)

Features

2.1.0 (2018-08-20)

Features

Performance Improvements

2.0.0 (2018-07-23)

Bug Fixes

Code Refactoring

Features

BREAKING CHANGES

SAXParser is now SaxesParser. So new require("saxes").SaxesParser(...). * The API based on Stream is gone. There were multiple issues with it. It was Node-specific. It used an ancient Node API (the so-called "classic streams"). Its behavior was idiosyncratic. * Sax had no default error handler but if you wanted to continue calling write() after an error you had to call resume(). We do away with resume() and instead install a default onerror which throws. Replace with a no-op handler if you want to continue after errors. * The "processinginstruction" now produces a "target" field instead of a "name" field. The nomenclature "target" is the one used in the XML literature. * * The ns field is no longer using the prototype trick that sax used. The ns field of a tag contains only those namespaces that the tag declares.

The feature always seemed a bit awkward. Client code could limit the size of buffers to 1024K, for instance, and not get a text event with a text payload greater than 1024K... so far so good but if the same document contained a comment with more than 1024K that would result in an error. Hmm.... why? The distinction seems entirely arbitrary.

The upshot is that client code needs to be ready to handle strings of any length supported by the platform.

If there's a clear need to reintroduce it, we'll reassess. * It is no longer possible to load the library as-is through a script element. It needs building.

The library now assumes a modern runtime. It no longer contains any code to polyfill what's missing. It is up to developers using this code to deal with polyfills as needed. * We drop the trim option. It is up to client code to trip text if it needs it. * We no longer support the normalize option. It is up to client code to perform whatever normalization it wants. * The lowercase option makes no sense for XML. It is removed. * Remove support for strictEntities. Entities are now always strict, as required by the XML specification. * By default parsers now have a default no-op implementation for each event it supports. This would break code that determines whether a custom handler was added by checking whether there's any handler at all. This removes the necessity for the parser implementation to check whether there is a handler before calling it.

In the process of making this change, we've removed support for the on... properties on streams objects. Their existence was not warranted by any standard API provided by Node. (EventEmitter does not have on... properties for events it supports, nor does Stream.) Their existence was also undocumented. And their functioning was awkward. For instance, with sax, this:

const s = sax.createStream(); const handler = () => console.log("moo"); s.on("cdata", handler); console.log(s.oncdata === handler);

would print false. If you examine s.oncdata you see it is glue code instead of the handler assigned. This is just bizarre, so we removed it.