Re: Parsing large amounts of data (200,000 entries) with XML?
From: Joseph M. Ferris (josephmferris_at_cox.net)
Date: 03/14/04
- Next message: Joseph M. Ferris: "Re: Parsing large amounts of data (200,000 entries) with XML?"
- Previous message: Bonj: "Re: Parsing large amounts of data (200,000 entries) with XML?"
- In reply to: Bonj: "Re: Parsing large amounts of data (200,000 entries) with XML?"
- Next in thread: Bonj: "Re: Parsing large amounts of data (200,000 entries) with XML?"
- Reply: Bonj: "Re: Parsing large amounts of data (200,000 entries) with XML?"
- Messages sorted by: [ date ] [ thread ]
Date: Sat, 13 Mar 2004 18:04:20 -0700
I only respond to this after stating that none of these arguments are
actually presented by you, but are merely copied off of a web site. To
be exact from: http://c2.com/cgi/wiki?XmlSucks
With a page name like that, it hardly came from an objective source, did
it? ;-)
Bonj wrote:
> Perceived problems with XML:
> a.. It's too complex for what it does.
It is hardly complex. HTML is derived from SGML, as is XML. XHTML is
the marriage of HTML and XML. $12/hr "web developers" can handle both
with ease.
The author of the article percieves it as being too complex for what it
does. That is an opinion.
> b.. It's too hard for programs to parse and too verbose and unreadable for
> humans to write.
Look at the sample I provided for Jamie. That code is very, very basic.
To set up a parser to handle the same task with a text file will take
approximately the same amount of code. Granted, you have to learn an
object model to use the parser, but learning an object model is quite
common amongst Visual Basic developers.
Hierarchal structures are hardly unreadable, and even if it were, people
write software to generate data. XML is data, plain and simple.
Verbosity is part of the price that is required to have the ability to
present data in a hierarchal, and even object-driven models.
Like I have said in the past, I have a serialization component that can
save the state of a COM+ component - including all of its attributes.
It serializes it to a text file that mimics the structure of the object.
That XML can be placed on another server and be used to create that
COM+ components state to match the one in memory on the first server.
Originally, this was done without XML. The data file was only about
20%, but it was very hard to follow since it was storing nested
properties in a flat file. But, the code to parse the flat text file
was over twice as big as the same code that now handles the XML. Why?
Because I did not need to write handling code to convert the flat file
into a hierarchal structure. On top of that, I could attach attributes
to a piece of data. It was just like having properties on an object.
> c.. The benefits of "everyone is using XML, so we should too" are usually
> outweighed by the costs of time, training and mistakes involved in
> understanding it.
Training issues? Everyone is using Windows, lets keep on using DOS and
writing batch files... It is to costly and takes too much time to get
our users up on Windows. I remember that argument well.
If you are in a business where you need to sell your services or
products to the public, they demand that you use the most current
techologies. Don't blame the developers or the project managers -
remember that "the customer is always right".
We offer training sessions at work for new technologies as we accept
them into our development practices - which is something that more
companies should do. Of all of the different training sessions that I
have been involved in, I can say that XML was one of the easier concepts
for people to grasp. These are the same people who could not grasp the
fact that the SQL Server was on its own machine and that other machines
"talked to it". ;-)
> d.. Because it's increasingly used for data interchange, it is promoted as
> a data storage model. XML is only a data encoding format.
No. XML is a logical storage structure. What the user does with it is
driven by their needs. SOAP is billed as a data transport model. Does
SOAP use XML? Yes. Are all XML documents SOAP compliant? No.
The author is confusing the application of usage standards with the
standards that govern the structure of XML on a whole.
> e.. Encourages non-relational data structures
And flat files don't? Data structures on their own can not define any
sort of data relationships. It is the responsibility of the person who
defines the data structure, whether it be an analyst, developer, etc. to
correctly define the data structures that are going to be used.
> f.. Poor OnceAndOnlyOnce syntax factoring
See e. Nothing prevents a user from creating a lookup section in an XML
document and using pointers to refer to a single definitive data fragment.
> g.. It's a poor copy of EssExpressions
I have no experience with EssExpressions, but glancing at the text that
the article got this from, I can see that the comparison is weak. Just
because they both deal with hierarchal data does not make one a copy of
another.
But, I am not going to argue this point, since I have no experience. I
prefer to actually back up my arguments with experience, and I can not
do so here. Anyone here actually ever used SymbolicExpressions that can
enlighten us?
--Joseph
- Next message: Joseph M. Ferris: "Re: Parsing large amounts of data (200,000 entries) with XML?"
- Previous message: Bonj: "Re: Parsing large amounts of data (200,000 entries) with XML?"
- In reply to: Bonj: "Re: Parsing large amounts of data (200,000 entries) with XML?"
- Next in thread: Bonj: "Re: Parsing large amounts of data (200,000 entries) with XML?"
- Reply: Bonj: "Re: Parsing large amounts of data (200,000 entries) with XML?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
