neslib/neslib.xml

Ultra Light-Weight XML Library for Delphi

Neslib - Base library used by other Neslib projects

Neslib is a (still small) library of Delphi utilities that is shared across some other Neslib projects.

License

Neslib is licensed under the Simplified BSD License.

See License.txt for details.

neslib.xml's Issues

Problem reading a space value

Hi,

I'm not sure to consider this as a bug or as a feature :-), but a single space from a text element is never read (Write is OK).

Ex:
<?xml version="1.0" encoding="UTF-8"?> <MyElement MyAttribute="C&apos;est ici"> </MyElement>

MyElement text value will always be read as an empty string.
I've fixed this by changing the line 1015 in Neslib.Xml.IO.pas like this:

if (P^ > #$1F {#$20}) then

I understand the check you wanted to do here and in most cases it's ok but not if there's a single space.
I could not read in the XML specs that such a case is forbidden, so I think the single space should be read ?

Regards

Frédéric

Tiny.Library collaboration

Hello, Erik

I analyzed the sources of your libraries and came to the conclusion that the issue of optimization is very important for you. I have been programming in Delphi for over 20 years and spend a lot of time writing high-performance code. You can verify this by analyzing the benchmarks in my open source projects.

I would like to suggest that you use the Tiny.Library - it contains a lot of lightweight and high-performance code that works with text, data streams, RTTI, memory, generics and more. It is planned to supplement the library with routine testing, server applications, marshalling and more.

In fact, the library is a combination of the following libraries:

• Tiny.Rtti
• Rapid.Generics
• CachedTexts
• CachedBuffers
• UniConv

Nowadays there are not enough XML/JSON parsers and writers. Most Delphi parsers use standard strings for convenience. I think that in Tiny.Library this approach can be implemented, but as a superstructure on top of the low-level approach. I liked the approach in PugiXML, when addressing to pre-allocated memory occurs - this significantly speeds up the parsing process, especially in multithreaded applications, when each string allocation leads to the manager blocking. The library currently supports ALL possible XML encodings, including ALL possible BOMs. An automatic step-by-step encoding conversion has been implemented, which allows you to parse documents even several gigabytes in size, using only a few kilobytes of RAM. In addition, high-level functions are implemented for working with strings in pre-allocated memory, for example, for converting to a number or date - this will make it easy and convenient to use the fast parser in commercial products.

Writing high-performance code takes a lot of time and effort. The cost of making a mistake is very high. Since I am not an expert in XML/JSON, it is difficult for me to decide and take enough time to implement full-fledged parsers and writers. I need to collaborate with an expert who can consult, review code, and write automated tests. I suggest you consider this option. Contacts are listed in library units.

Running Tests

Compiled in 32 and 64 and get the same results
Delphi 11 Version 28.0.44500.8973

XML Performance Tests (64-bits)
Select XML library:
0. Delphi (Default)

1. MSXML
2. OmniXML
3. VerySimpleXml
4. SimpleXML
5. Alcinoe
6. Neslib (Unicode mode)

Enter library number: 6
Running test...

Memory usage : 44744 KB
Load time : 250.72 ms
ERROR: Invalid number of attributes (expected=56317, actual=56310)
Traverse time: 31.38 ms
Query time : 1.52 ms
Destroy time : 33.94 ms

Finished!

Does not support comments at the beginning of the file

XML with comments at the beginning of the file is not supported, which is not uncommon. For example, GrijjyDeployMan cannot correctly read the Skia4Delphi .dprojs due to the comments at the beginning of the document: https://github.com/skia4delphi/skia4delphi/blob/main/Samples/Demo/FMX/Projects/RAD%20Studio%2011%20Alexandria/Skia4Delphi.dproj

XPATH

Your code is awesome.
There is any plan for XPATH?

Thank you very much,
Paul

A bit strange code

I have some doubts that this code does exactly what it should:

function TXmlDocument.GetDocumentElement: TXmlNode;
begin
  if (FRoot <> nil) then
  begin
    Result := FRoot.FirstChild;
    while (Result <> nil) do
    begin
      if (Result.NodeType = TXmlNodeType.Element) then
        Exit;
    end;
  end;
  Result.FNode := nil;
end;

Especially the part of it that is inside the while-loop...

Method for getting the text of an element

This library definitely lacks a property or method to get text from a node.

XmlNode := XmlDoc.DocumentElement.ElementByName('Name').FirstChild;
while XmlNode <> nil do
begin
  if XmlNode.NodeType = TXmlNodeType.Text then 
    Break;
  XmlNode := XmlNode.NextSibling;
end;
SomeThing = XmlNode.Value;

Or did I just not find a way to do it simply?

TXmlReader.ParseComment throws parser error for valid XML comments

Symptom

The while loop in TXmlReader.ParseComment which should handle nested angular brackets seems to be unable to handle the following valid XML comment properly and subsequently the method throws a parser error exception about an invalid comment.

<!--FOO>
    <BAR IDREF="01"/>
</FOO-->

Analysis

Since the while loop expects nested angular brackets to always start with an opening bracket, the number of levels in the above example immediately decreases to 0 at the end of the first line and the loop is exited. The "--" then cannot be found before the current position and the mentiond parser error is raised.

Also, the loop seems to expect an identical amount of opening and closing angular brackets. This seems to be an invalid assumption for a comment that can contain anything.
So I expect this

<!-- All of >>>this<<<<<<<< is a comment -->

to also throw an exception.
I can also think of examples that might cause the parser to leave to scope of the comment:

<!-- All of this is a comment<<<< -->

Suggestions

I think the while loop should look for the first occurrence of the closing sequence "-->" instead of counting the level of nested angular brackets.
Maybe something like this:

procedure TXmlReader.ParseComment;
begin
  var P := FCurrent;
  if (P[0] <> '!') or (P[1] <> '-') or (P[2] <> '-') then
    ParseError(@RS_XML_INVALID_COMMENT);

  Inc(P, 3);
  var Start := P;
  var Closed := False;

  { Move to end of comment. }
  while not Closed do
  begin
    if (P^ = #0) then
      ParseError(@RS_XML_UNEXPECTED_EOF);

    Closed := (P >= (Start + 2)) and (P^ = '>') and (P[-1] = '-') and (P[-2] = '-');
    Inc(P);
  end;

  SetString(FValueString, Start, P - Start - 3);
  FCurrent := P;
end;

Thank you!