The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,422 other followers

Delphi Research list: TXMLDocument binding for OmniXML (via: Stack Overflow)

Posted by jpluimers on 2014/11/18

This should not be difficult to do, just time consuming. So it is on my research list to see how time consuming: build a TXMLDocument binding for OmniXML.

This is to urge less people to try to parse XML by hand like xml – Copy & Copy does not work correctly with stringlist – Stack Overflow.


via: Delphi, OmniXML – XML binding? – Stack Overflow.

13 Responses to “Delphi Research list: TXMLDocument binding for OmniXML (via: Stack Overflow)”

  1. […] a comment by IL on Delphi Research list: TXMLDocument binding for OmniXML (via: Stack […]

  2. FYI, a TXMLDocument binding for OmniXML ships in XE7.

    • jpluimers said

      Thanks for the update. If my SSD wasn’t full of Delphi installer files in $(ProgramData) I’d have space to upgrade.

      • IL said

        Jeroen, most of install files can be deleted. You may delete all files in ProgramData{guid} folders except OFFLINE folder and files in the folder itself. This is sufficient for installer’s remove functionality and you still can modify and recover your installation from the separate setup on the ISO image or web setup. I’ve learnt this little trick at one of Russian Delphi forums. I’ve deleted the Delphi installation files in ProgramData myself, no issues yet, but I’ve never tried to install the update, modify or recover after that. Going to try with XE7 Update1.

  3. SpeedFreak said

    One thing to be aware of when using TXMLDocument is that it doubles the amount of memory used when loading and saving documents, since it effectively duplicates the nodes of the vendor library it wraps. For simple or small documents this is probably not a problem, but for large documents it becomes the limiting factor in how large documents one can support.

    • jpluimers said

      So you mean for large XML streams: use a vendor specific DOM, right?

      What order of magnitude is “large”? Something like 10 megabytes? 100? 1 gigabyte?

      • SpeedFreak said

        I don’t known what you mean by DFM.
        Personally I only use TXMLDocument when I know the size of the documents will not be a problem and when I do I always use the MSXML vendor. My tests has shown that MSXMLs performance is quite good (better than most (not all) of the native Delphi libs). TXMLDocument does have some nice convenience features but apart from that, and if cross platform doesn’t matter (it doesn’t for me), one might as well use the XML lib directly.

        The problem with duplication isn’t the data values (those aren’t duplicated) but the data structure (nodes are duplicated). Many nodes = much overhead.
        “Large” really depends on what you do with the data. E.g. if the document structure correlates to your internal data structure then, when you load or save a document, each node will actually be represented three times in memory at the end of the operation. One in the vendor lib, one in TXMLDocument and one in your own structure. Remove TXMLDocument and it’s only twice. Use a SAX parser and it’s only once.

        For example in one of our applications we use XML to exchange data between Building Information Modeling systems and CAD systems. For large construction projects a document can easily contain millions of nodes with very little data in each node. I found that once I eliminated TXMLDocument we could typically load documents that were 25% larger than before.

        • jpluimers said

          DFM was an auto-correct thing on my mobile phone. Sorry for that. Fixed in the original comment as DOM.

          Thanks a lot for the elaborate answer. I was hoping it would be a node-count thing, not a full data duplication thing, as that confirms my understanding of the inner TXMLDocument structures.

        • Lars Fosdal said

          So, which SAX parser to chose? Is there a native one for Delphi?

          • jpluimers said

            +Lars Fosdal I have no idea. When doing XML, I usually pick .NET as it is has most of what I need built-in or a good open source library for it. Though it has no SAX reader built-in, the XmlReader is good and lightweight. And there is a good open source SAX reader available. 

Leave a Reply to jpluimers Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: