0.4.4

Fixed a bug preventing parsing attributes in CTFE and clarified some documentation.

• Fixed bug where attributes could not be parsed during CTFE due to limitations with std.typecons.Tuple.
• Updated documentation for #25.

0.4.3

Fixed it so that dxml compiles with -inline.

• For some reason, dmd fails to inline a couple of the functions marked with pragma(inline, true) (which cause a compilation error with -inline), so at least until that's fixed, they're no longer marked with pragma(inline, true).

0.4.2

Added tests for and fixed handling of char[].

• Fixed dxml issue #23: decodeXML does not compile when given a range of type char[].

0.4.1

A few minor fixes.

• Fixed some uses of Nullable to get rid of deprecation messages related to its alias this being deprecated. However, there is one that I've seen pop up when projects use dxml (it also pops up with dxml's unit tests) which I have not been able to track down. Namely:

  /usr/local/include/dmd/std/range/primitives.d(174,38): Deprecation: function std.typecons.Nullable!string.Nullable.get_ is deprecated - Implicit conversion with alias Nullable.get this will be removed after 2.096. Please use .get explicitly.

  It looks like somewhere, a range of Nullables is being tested to see whether it's an input range or not, and that test results in the deprecation message being printed, but I have no clue where the code is that's using isInputRange and thus triggers the deprecation message.

  Using a version of Phobos where Nullable'salias this has been completely removed instead of deprecated results in dxml's tests building and passing just fine. So, it seems that whatever is going on doesn't actually require that any code be changed because of the deprecation, much as it's annoying to have the deprecation message being printed.

• Fixed #14: The missing message was added to the assertion in DOMEntity.children.

• Fixed #19: dxml.util.stripIndent was fixed to properly handle the case where the second line was just whitespace, and the first line did not start with whitespace.

0.4.0

Most of the changes involve improving the handling of start tag attributes. dxml.parser.getAttrs in particular is likely to be of interest to those looking to reduce the amount of code necessary when dealing with start tag attributes.

• The deprecated aliases, dxml.util.normalize and dxml.util.asNormalized, have been removed. Any code that has not yet been updated to use decodeXML and asDecodedXML will no longer compile until it's been updated.

• EntityRange.Entity and DOMEntity now have an alias named Attribute which contains the exact instantiation of std.typecons.Tuple that their attributes functions return ranges of. This will make it easier to refer to them by their exact type when required (e.g. when creating an output range of them).

• The trait dxml.parser.isAttrRange has been added. It's true if the given type is a range of attributes such as those returned by EntityRange.Entity.attributes and DOMEntity.attributes.

• The function dxml.parser.getAttrs has been added. It's essentially the XML attribute equivalent of getopt.

• Fixed dxml issue #10: Made internal function, skipStartsWith leverage std.algorithm.searching.skipOver

• EntityRange now uses Appender internally instead of using dynamic arrays directly for handling the validation of tags and attributes, since benchmarking indicated that using Appender was slightly faster.

0.3.2

• Fixed dxml issue #8: ldc fuzz testing found a few cases where empty was not checked properly on the range being parsed by EntityRange, and those have now been fixed.

• EntityRange and DOMEntity now work in CTFE.

0.3.1

Minor update to fix bug in encodeText.

• "]]>" is not legal in the text field of an XML document, which was properly caught by XMLWriter.writeText, but dxml.util.encodeText failed to handle it, leaving it as "]]>". encodeText now converts "]]>" to "]]>".

0.3.0

The biggest changes here are that basic writer support has been added with dxml.writer and that throwOnEntityRef was added to the parser config for managing how non-standard entity references are handled.

• dxml.writer has been added. It provides functionality for creating XML documents.

• The deprecated dxml.parser.stax (the old name for dxml.parser) has been removed. Any code that has not yet been updated to use dxml.parser instead will no longer compile until it's updated to import dxml.parser instead of dxml.parser.stax.

• Fixed dxml issue #5: dxml.parser.Config has a new option: throwOnEntityRef. It controls how EntityRange handles entity references.

  Any entity references other than the five defined by the XML spec must be declared in the DTD, and dxml does not support parsing the DTD beyond what is required to skip it. So, dxml cannot correctly handle such entity references. Prior to this release of dxml, EntityRange always threw when encountering such entity references. Without DTD support, the only alternative would be to ignore them, and doing so means losing an unknown amount of XML (since they can refer to arbitrarily complex XML), which could be a non-issue or a complete disaster depending on the XML document and what the program is trying to do. However, that tradeoff may be acceptable to some programs, particularly since the alternative is not being able to parse the document at all past the point that such an entity reference is encountered.

  So, with this release, Config.throwOnEntityRef has been added. The default is ThrowOnEntityRef.yes, which is the same behavior as in previous releases of dxml - an XMLParsingException is thrown if a non-standard entity references is ecountered. However, if throwOnEntityRef == ThrowOnEntityRef.no, then non-standard entity references are treated as normal text so long as they are syntactically valid (i.e. they have to contain the correct characters to be a valid entity reference). As the DTD was not parsed, they are not semantically validated (and thus may or may not have been correctly declared in the DTD), and they are not replaced with whatever they refer to (which EntityRange doesn't even do with the five predefined entity references, since that doesn't work with its slicing semantics). So, aside from the fact they they are semantically validated, they are treated as normal text and passed on to the application.

  simpleXML.throwOnEntityRef == ThrowOnEntityRef.yes, so its behavior is unchanged.

• Fixed dxml issue #4: Renamed normalize to decodeXML and asNormalized to asDecodedXML. The old names are still provided as deprecated aliases but will be removed in dxml 0.4.0.

  The new names fit better with the newly added writer functionality and don't risk conflicting with std.utf.normalize (which is a function that is fairly likely to be used in conjunction with dxml and would therefore have resulted in symbol conflicts).

• Fixed dxml issue #3: Improved the error message when the XML document has whitespace before the <?xml...?> declaration.

• Fixed an @safety bug in asDecodedXML/asNormalized. Internally, the return type maintained a static array of code units for a decoded character reference, and a dynamic array which sliced it to keep track of the iteration through that buffer. It was smart enough to use the postblit constructor to fix-up the dynamic array when the struct was copied, but it did not take into account the fact that the struct could be moved, in which case the dynamic array would refer to an invalid slice of memory and produce the wrong results. Without -dip1000, the compiler doesn't catch that @safety hole, and -dip1000 isn't ready yet, so it wasn't caught by the compiler when testing dxml. Fortunately, that particular issue was recently discussed in D.Learn with regards to -dip1000 as well as in the discussions which sparked the opMove DIP. So, the @safety bug in asDecodedXML/asNormalized was discovered, and it has now been fixed.

0.2.3

Fixed linker errer when building unit tests for a project that dependend on dxml.

• Projects that depended on dxml and built their own unit tests were failing to build due to linker errors. For whatever reason, some symbols from dxml's unit tests weren't linking in properly, but really they shouldn't have been being built in the first place, since they're dxml's unit tests, not the unit tests of any project that depends on dxml. But unfortunately, by default, dub uses the unittest build for all dependencies if a project's unittest build is built, meaning that projects end up compiling and running unnecessary unit tests and that it only gets worse the more libraries a project depends on - even if they don't end up with linker errors like is happening with dxml.

  So, to work around this unfortunate behavior, dxml now has a doTests build type to run its unit tests, and all of the unit test stuff has been versioned off with a dxml-specific version identifier. So now, not only are the linker errors gone, but projects using dxml don't have to worry about inadvertently building and running dxml's unit tests.

0.2.2

Quick update to improve error messages for failed in contracts.

• Various functions assert that the EntityType of the current entity is correct when they're called, but the assert statements didn't have any messages, meaning that anyone who got the failure would have to look at the source code to figure out what they did wrong. Now, each of those assertions has error messages which say what the programmer did wrong.