I am looking for a straight-forward no frills XML library or component
that allows me to easily form an XML file and to parse it easily as a
means to transfer text (could be long and lengthy) information back
and forth between applications. I would appreciate any recommendation
of such a resource. Or maybe XML is not a good option for my
application?

Thanking you all in advance. 

Andy

Andy wrote:

> I am looking for a straight-forward no frills XML library or component
> that allows me to easily form an XML file and to parse it easily as a
> means to transfer text (could be long and lengthy) information back
> and forth between applications.

Did you try the TXMLDocument framework that is built-in to Delphi?  There 
are, of course, third-party XML libraries as well.

> Or maybe XML is not a good option for my application?

Hard to say without knowing what your application does or what kind of data 
it needs to exchange.

--
Remy Lebeau (TeamB)

Hi Remy, 


>Did you try the TXMLDocument framework that is built-in to Delphi?  There 
>are, of course, third-party XML libraries as well.

I have not tried TXMLDocument in Delphi yet. Any good examples out
there that I can gather? 

>Hard to say without knowing what your application does or what kind of data 
>it needs to exchange.

I have text categorized as "Comments" which can carry a fair amount of
text to go with several fields like Name, Code, etc. basically
resembling something for books in libraries where the large text could
be the description of the book or even excerpts. I don't want to
resort to database usage if I can help it. But not sure how this would
affect speed with that much text flying around. Also, is there a
limitation as to the amount of text that can be in an XML file? 

Thanks Remy. 

Andy

I've recently purchased OXml - I haven't widely used it yet but seems 
good so far. Also cross-platform in case you head that way in future.

https://www.kluug.at/kluug-net/oxml.php

Cheers, Bob

Andy wrote:

> not sure how this would affect speed with that much text flying around.

That depends on how you are sending it.

> Also, is there a limitation as to the amount of text that can be in an 
XML file?

Generally just available memory.  Working with large XML documents may take 
alot of memory, depending on how you are processing the XML.  For generating 
XML, a DOM tree is usually created before the final XML string is then formatted, 
and that tree can take a lot of memory.  You might think of serializing your 
data to the final XML string directly to avoid needing a tree (TXMLDocument 
does not support that).  For parsing XML, parsing into a DOM tree can also 
take a lot of memory, so you might use a SAX parser instead (TXMLDocument 
does not support that).

--
Remy Lebeau (TeamB)

Thanks Bob for the info. Looks promising. 

Andy

On Sun, 8 Jun 2014 01:34:42 -0700, Bob Devine <bd@nospam.net> wrote:

>I've recently purchased OXml - I haven't widely used it yet but seems 
>good so far. Also cross-platform in case you head that way in future.
>
>https://www.kluug.at/kluug-net/oxml.php
>
>Cheers, Bob

Thanks Remy for the pointers. I will search around for a SAX parser in
the meantime. How would one serialize the data and if that is needed,
what third-party XML supports that? 

Andy

On Sun, 8 Jun 2014 12:46:43 -0700, Remy Lebeau (TeamB)
<no.spam@no.spam.com> wrote:

>Andy wrote:
>
>> not sure how this would affect speed with that much text flying around.
>
>That depends on how you are sending it.
>
>> Also, is there a limitation as to the amount of text that can be in an 
>XML file?
>
>Generally just available memory.  Working with large XML documents may take 
>alot of memory, depending on how you are processing the XML.  For generating 
>XML, a DOM tree is usually created before the final XML string is then formatted, 
>and that tree can take a lot of memory.  You might think of serializing your 
>data to the final XML string directly to avoid needing a tree (TXMLDocument 
>does not support that).  For parsing XML, parsing into a DOM tree can also 
>take a lot of memory, so you might use a SAX parser instead (TXMLDocument 
>does not support that).

Not too sure your data XML structure. If there is no deep hierarchy in the tree, you may like to try ClientDataSet. It can read XML into a database table or vice versa. 
You can easily do many data processing as you do in a table. If your data cannot be easily transformed into a table like format, you have to go with TXMLDocument or third party. 
Generally, XML is heavily redundant data structure. Not sure if this helps.


> {quote:title=Andy Colmes wrote:}{quote}
> Thanks Remy for the pointers. I will search around for a SAX parser in
> the meantime. How would one serialize the data and if that is needed,
> what third-party XML supports that? 
> 
> Andy
> 
> On Sun, 8 Jun 2014 12:46:43 -0700, Remy Lebeau (TeamB)
> <no.spam@no.spam.com> wrote:
> 
> >Andy wrote:
> >
> >> not sure how this would affect speed with that much text flying around.
> >
> >That depends on how you are sending it.
> >
> >> Also, is there a limitation as to the amount of text that can be in an 
> >XML file?
> >
> >Generally just available memory.  Working with large XML documents may take 
> >alot of memory, depending on how you are processing the XML.  For generating 
> >XML, a DOM tree is usually created before the final XML string is then formatted, 
> >and that tree can take a lot of memory.  You might think of serializing your 
> >data to the final XML string directly to avoid needing a tree (TXMLDocument 
> >does not support that).  For parsing XML, parsing into a DOM tree can also 
> >take a lot of memory, so you might use a SAX parser instead (TXMLDocument 
> >does not support that).

Hello Haizhou, 

Thank you for the insight on this. ClientDataSet could definitely be
an option. 

Andy

On Sun, 8 Jun 2014 13:56:41 -0700, Haizhou Tang <> wrote:

>Not too sure your data XML structure. If there is no deep hierarchy in the tree, you may like to try ClientDataSet. It can read XML into a database table or vice versa. 
>You can easily do many data processing as you do in a table. If your data cannot be easily transformed into a table like format, you have to go with TXMLDocument or third party. 
>Generally, XML is heavily redundant data structure. Not sure if this helps.
>
>
>> {quote:title=Andy Colmes wrote:}{quote}
>> Thanks Remy for the pointers. I will search around for a SAX parser in
>> the meantime. How would one serialize the data and if that is needed,
>> what third-party XML supports that? 
>> 
>> Andy
>> 
>> On Sun, 8 Jun 2014 12:46:43 -0700, Remy Lebeau (TeamB)
>> <no.spam@no.spam.com> wrote:
>> 
>> >Andy wrote:
>> >
>> >> not sure how this would affect speed with that much text flying around.
>> >
>> >That depends on how you are sending it.
>> >
>> >> Also, is there a limitation as to the amount of text that can be in an 
>> >XML file?
>> >
>> >Generally just available memory.  Working with large XML documents may take 
>> >alot of memory, depending on how you are processing the XML.  For generating 
>> >XML, a DOM tree is usually created before the final XML string is then formatted, 
>> >and that tree can take a lot of memory.  You might think of serializing your 
>> >data to the final XML string directly to avoid needing a tree (TXMLDocument 
>> >does not support that).  For parsing XML, parsing into a DOM tree can also 
>> >take a lot of memory, so you might use a SAX parser instead (TXMLDocument 
>> >does not support that).

There is also NativeXML http://www.simdesign.nl/xml.html

It used to be commercial, now open source, as the original author got into an accident and open sourced the product. Because of that, support is not great, and improvements are slow. However, the price is right and it is quite a complete package that handles both DOM and SAX parsing.  They also have a TReader and TWriter descendent to stream your objects to XML.

David Novo wrote:

> There is also NativeXML http://www.simdesign.nl/xml.html
> 
> It used to be commercial, now open source, as the original author got
> into an accident and open sourced the product. Because of that,
> support is not great, and improvements are slow. However, the price
> is right and it is quite a complete package that handles both DOM and
> SAX parsing.  They also have a TReader and TWriter descendent to
> stream your objects to XML.

+1 for NativeXML

Thanks David for the info. I knew of NativeXML but never really give
it a spin. I will try now. 

Andy

On Sun, 8 Jun 2014 21:13:23 -0700, David Novo <> wrote:

>There is also NativeXML http://www.simdesign.nl/xml.html
>
>It used to be commercial, now open source, as the original author got into an accident and open sourced the product. Because of that, support is not great, and improvements are slow. However, the price is right and it is quite a complete package that handles both DOM and SAX parsing.  They also have a TReader and TWriter descendent to stream your objects to XML.

Call me crazy, but in 2014 shouldn't XML parsing be in the standard library?