Yes, XML is highly compressable, but so is CSV. If I am in control of both ends of the transaction, I can control everything in that second point. I don't have to worry about things that aren't going to happen. If I am expecting 4 elements, and 5 arrive, then that fifth element is dropped. Same thing that happens if an xml parser encounters an unexpected or unused element.
No XML parser I have seen is simpler than a CSV parser. XML is far more complex than CSV. The XML parser has to be able to deal with node data and attributes. It has to know that some nodes are self closing while others are not. The options with a CSV file are what is the field delimiter, if there is a string delimiter, what is it and how do you escape it, and finally what do you do with an empty field. That's it. XML has the escape and empty element issue as well, but the solutions are far more complex than just double the delimiter because there are more characters that can cause an issue. Open up even a simple XML parser, and you will find way more than a couple dozen lines of code. You could easily write a single pass parser that will take into account all of the CSV issues brought up here in a couple dozen lines of RPG, and that parser could then be called to get the next token in any CSV application. Just understand I'm not comparing writing the CSV parser with using an XML parser, consider the amount of code in Xerces or eXpat. They are huge, and if you are planning to use Java, that XML library in Java has a lot of code behind it.
I am not arguing the usefulness of XML when you don't know what you are going to get. But if the data has to be formatted in a specific manner, and all others will fail, then XML has a lot of overhead.
Now the trivial cases we have been bantering about would mean nothing either way, but when you start sending large amounts of data, XML (even if it compressed) will be about the same size as the uncompressed CSV file. Most XML files can be compressed down 80-90%. But the problem is that XML is 80-90% overhead. Even if you can only compress the CSV file 70%, that is 70% smaller than the compressed XML data stream just because the compressed XML started out about the same size as the uncompressed CSV.
Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx
-----midrange-l-bounces@xxxxxxxxxxxx wrote: -----
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
From: Dan Kimmel
Sent by: midrange-l-bounces@xxxxxxxxxxxx
Date: 12/03/2012 11:15AM
Subject: RE: Re: What style of RPG program can communicate with PHP?
You're assuming all those repeated characters go across the wire. Invalid assumption. Most browsers compress the http content. The http server decompresses it. (Compression/decompression may occur at lower levels of the protocol stack, but it doesn't really matter, does it?)
An XML parser is actually a lot simpler than a CSV parser. Why? There are solid rules about handling characters in the body of the message that duplicate meta-characters. And, there are fewer meta-characters. What happens to your CSV parser when you want a comma in the data field? How does your CSV parser react when there are five elements rather than four?
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Mark Murphy/STAR BASE Consulting Inc.
Sent: Monday, December 03, 2012 9:15 AM
To: Midrange Systems Technical Discussion
Subject: Re: Re: What style of RPG program can communicate with PHP?
XML adds to network congestion, and processing time.
Much less effort to parse
ABC,2012-05-01,25,0
(19 bytes)
vs.
<request>
<customer>ABC</customer>
<orderdate>2012-05-01</orderdate>
<pagesize>25</pagesize>
<prevpage>0</prevpage>
</request>
(122 bytes)
If you know the format of the record, which is true if you control both sides of the transaction, then parsing the CSV is far more efficient than parsing the XML. XML parsers use a lot of resources. To parse a CSV only takes a few lines of code.
Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx
-----midrange-l-bounces@xxxxxxxxxxxx wrote: -----
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
From: Alan Campin
Sent by: midrange-l-bounces@xxxxxxxxxxxx
Date: 11/30/2012 05:37PM
Subject: Re: Re: What style of RPG program can communicate with PHP?
So given an example of a screen that allows the operator to enter one or more criteria to search on say invoices it would take a lot of overhead to parse?
<request>
<customer>ABC</customer>
<orderdate>2012-05-01</orderdate>
<pagesize>25</pagesize>
<prevpage>0</prevpage>
</request>
On the PC side you can just map the XML to an object or least you can in Java and I assume PHP would have the same kind of capability.
I would suspect the time to pass through the wire would be many times greater than the overhead of parsing the XML.
On Fri, Nov 30, 2012 at 3:19 PM, Mark Murphy/STAR BASE Consulting Inc. < mmurphy@xxxxxxxxxxxxxxx> wrote:
XML is 80-90% overhead. All that metadata built into each and every
document is largely unnecessary fluff. If you control both ends of the
transaction, it is better to use some other format. Just my own
personal opinion.
Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx
-----midrange-l-bounces@xxxxxxxxxxxx wrote: -----
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
From: Alan Campin
Sent by: midrange-l-bounces@xxxxxxxxxxxx
Date: 11/30/2012 05:12PM
Subject: Re: Re: What style of RPG program can communicate with PHP?
OK, but how do you parse the JSON? There are all kinds of choices for
parsing XML including built into the RPG language. Hard for me to
believe that XML has that much overhead.
On Fri, Nov 30, 2012 at 2:44 PM, Nathan Andelin <nandelin@xxxxxxxxx>
wrote:
send everything back and forth as XML ...
Good point about using messages, but see how streamlined JSON is;
addressing your concerns about performance (generating and parsing XML).
Simple Variable:
"hello world"
Basic Array:
["a","b","c",4,5,"six"]
Basic Object (name-value pairs):
{"firstName":"John","lastName":"Doe"}
Object Array:
[{"firstName":"John","lastName":"Allen"},{"firstName":"Anna","lastName
":"Smith"},{"firstName":"Peter","lastName":"Jones"}]
2-Dimensional Basic Array:
[["one","two","three"],["four","five","six"],["seven","eight","nine"
]]
-Nathan
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please
take a moment to review the archives at
http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
