What is the advantage of XML?

PHP
41

I don’t see a difference if you are to pass an image as a single file (image.jpg), or a binary data (image.xml or image.txt). It depends on what the developer intends to do and what problem he has to solve.

42

And one last, XML database vendors:

43

But is there also a formal definition of “data-centric model” ?

(Remember why we moved from a structured/hierarchical model to a relational model?)

44

Well, there are some differences :slight_smile:

For example, you can’t stuff anything you want in CDATA. So if you want to do it anyway, you’ll have to use for example base64encode. And let’s not forget the overhead of that.

Even Microsoft seems to realize that if i look at their new Office XML documents. (A zip container with binary files and XML files (with references to the binary files)

45

Yet there is no difference, there is only data, and a way to submit it. It is just a simple developer’s choice.

Good or bad, who can bet on it?

46

Thanks, when I have the time, I’ll be sure to look through those links and study the advantages of XML “databases”. Maybe I’ll learn a thing of two and see the light.

However to this point, myself and developers I work with see nothing more in XML than a standard, helpful way to make data available to anyone or anything without sweating how the data should be formatted.

At the present moment… we sure as heck are not about to ditch MS SQL Server to store our data in a bunch of XML files. Doing so would gain nothing and cost us a lot of convenience in functionality, such as stored procedures and triggers, user defined functions… I could go on and on.

I have found a few uses for XML to store data… only because it needs to be available to other applications. It’s value lies in the exchange of data, not storage. For simple data storage, there is no need to get away from regular database software. Just my HO.

47

I’ve never said XML is meant to be a replacement for a database. But it can be used like one.
Read that again to see that in your second sentence you say that XML can be used as a replacement for a database.

And one last, XML database vendors:
Because lots of people are selling products does not mean the technology behind it is a good thing. Sure it can be made into some working product, but that does not mean the product is good.

48

I think there is a difference between “is meant to be” and “can be used as”.

But it may indicate a demand, which may in turn might mean that people find it useful (whether you do or not). There certainly cases where being able to talk to a database directly using XML would be easier than converting back and forth.

49

I only read the first few posts, but I thought I’d chime in my experience using xml.

A long time ago I built an online job application system, that soon grew to have all kinds of requirements that the client desired. They wanted to display the job application in pdf to print out for interviews. They wanted to import applications into some propietary medical database (it was a hospital). Finally, they also expressed a desire to perhaps be able to import the data to a different system in the future. Internally, I also desired maximum reuse.

When I began refactoring with these objectives, XML as the data format became a strong candidate. I used XSL-FO to transform the xml to a pdf. I used XSLT for templating and this fit nicely with keeping the application in an XML data format. Also, the fact the data is in xml allows future developers to do whatever they want with it. I never got around to importing the data into their propietary medical system, but a general idea that was brainstormed would be to use SOAP to send the application data to the server and somehow import it from there.

With XSL, you can transform xml into anything you want really, heck you could even transform it to office xml to view, say, as a word document. Now people have stated they prefer csv over xml, but I would like someone to explain to me how they handled nested data that is heirarchical in nature as csv?

I mean it’s easy to scream why do this:


<id>2</id>
<name>James</name>
<whatever>blah</whatever>

when you could just do this:


id,name,whatever
2,James,blah

That is convenient, and in fact it may be better to use route two. But my system required data like this:


<application id="0002123">
 <metadata>
  <submitDate>2005-03-02</submitDate>
  <recruiter>
   ... recruiter data ...
  </recruiter>
 </metadata>
 <personalInformation>
  ... personal info ...
 </personalInformation>
 <employmentHistory>
  <employmentRecord id="21">
   <employer>
    <name>Evil, Inc.</name>
    <address>
     <street />
     <city />
     <zip />
    </address>
    <supervisor />
   </employer>
   <startDate />
   <endDate />
   <leaveReason />
  </employmentRecord>
 </employmentHistory>
</application>

Although that is a very quick write up off the top of my head, the actual xml is quite complex at times… sending this data as possibly hundreds of csv snippets seems rather redundant, doesn’t it?

50

How do you refactor objectives? Would be nice if you could explain that, because i’ve never seen someone do that. And it could allow me to understand why XML became a strong candidate.

How do you keep the application in an XML data format? (Btw, as long as you have a tool that is able to generate XML, XSL can be used to transform it to the desired output)

That is true for every data format you use (Assuming you document it as good as you would do with the XML format)

To me it sounds like there hasn’t been much brainstorming. It’s more or less the same as saying, we’ll use a freezer to store the application data and somehow import it from there.

Could you explain why you think that csv is heirarchical in nature? Which part of a cvs file could be considered the root? And which parts would be the nodes/leaves?

(Imho, the example you’ve shown is easily represented in a Relational model)

Sending this data as plain text (xml) seems rather redundant, doesn’t it? You could easily archive it (bz2, zip, tar, …)

Btw, you shouldn’t care about the number of files either. They will be processed by machines, not humans :slight_smile:

51

Perhaps the best of XML is that now there are existing parsers for it in almost every language. It wasn’t the case several years ago.
For example. In my current project I write a Java application, that is going to output XML files for web use with PHP, Java, JavaScript, etc.
If I used some other format, I should write the parsers myself :(.

52

XML is just the easiest way to multiple platforms and multiple languages, and as an extra plus you can save relationships inside of them. It will not replace databases in big systems, but for very small systems it is the ideal database.

It’s due to its simplicity that people love to adopt it and marketing helped popularising it ofcourse (XHTML, XForms, SVG, RDF). And XSLT made it versatile, what is not to love…

53

Hi,

Plain XML is hierarchical, which means that all related elements must be nested within the elements there’re related to.
When processing XML, an element isn’t actually complete until you reach its end tag.
If an application is parsing and XML document into elements in memory before transferring them into another
persisted form of data, this means that the elements that contain other elements must be retained in memory
until their internal data members are processed.
This results in some fairly significant strain on memory use, especially with larger documents.

RDF does not require this nested structure, RDF/XML you can associate two seperate XML structures with each other
though a Uniform Resource Identifier (URI) with the URI you can link one XML structure to another without having to
embed the second structure directly within the first.

davro

54

Haha, was reading another thread and came across this as a sig:

I think this says it all.

Also, just noteing … SVG is one area where XML is playing big - just look at Adobes support for this format.

From what I know google maps uses XML along the same lines as SVG.

I’d say adopting a DB architecture for that app would have been very difficult to implement.

55

Hehe, i said that already in #14 :slight_smile:

Why would it be the ideal database?

How would you handle n-m relationships in XML?
How would you handle transactions and concurrency with XML?
How about performance? How do you declare constraints? And how do you enforce them?

56

"Any fool can write code that a computer can understand.
Good programmers write code that humans can understand."M.Fowler
No because Martin Fowler is talking about code, we are talking about data. There’s a big difference! In fact the data we are talking about is meant to be created and read by computers as exchange format, no human should ever need to read it. So there goes your argument.

And I never implied you said that.

You are right about that I guess.

But it may indicate a demand, which may in turn might mean that people find it useful (whether you do or not).
XML is a buzzword, that explains the demand.

There certainly cases where being able to talk to a database directly using XML would be easier than converting back and forth.
Of course if you use XML in other parts of your application, it is easier to talk to a database with it. But then the question arises (again) why did you need to use XML in your application in the first place.

57

Sorry for being a bit hasty, with small I meant 1 person-can-edit-more-people-can-read-from-it, so concurrency/transactions would not be an issue.

and for the n-m thing:
<a>
<b></b>
</a>
<a>
<b></b>
<b></b>
</a>

constraints become simple business-logic.

They’ve did it once in the firm I work for, for a customer of ours, and it worked like a charm.

58

XML is a buzzword, that explains the demand.

Not more than my name (Dr Livingston) is a buzzword in my view :slight_smile: Xml is not a new technology, it’s been around for a number of years now, and it’s pretty much been taken as second nature.

To explain the demand however, for Xml, you need to understand the underlying technologies that use it, from SAX to Web Services, etc. This is why Xml has far more advantages over and above what CSV could ever offer.

I’m not saying CSV is obsolete, it isn’t (well, not quite yet anyways) but it’s a changing world, and Xml takes presedence, doesn’t it?

Plus it is trivially imported into all data manipulation software like databases and spreadsheets.

Well that is true, but so much so, the same can be said of Xml, and I’d even go as far as saying that Xml has wider application usage, as suggested for example, SVG being one such application :slight_smile:

59

My understanding of XML is that it provides a way to describe data. By providing a description you inadvertently make it human readable.

60

XML has one very big minus.
The characters used in the element tags may be only ASCII characters. That makes XML discribe data only for the English aware.
What about the rest of the world :wink: