Page 2 - Why Learn XML?

Ah, I see what yor getting at! I hadn't thought of XML as an B2B interface, as everyone I've talked to about it has been raving it as the replacement to HTML and makes doine web pages "so much easier". I do apologise for my ignorance but only with questions can ignorance be slain.

Well, I've been in XML only since I found the real meaning, not what people said at the beginning.

I think that with that great efforts from W3C to standarize an HTML version, all browsers trying to fit in that standards, and a lot of expert web developers trying to follow their guidelines, such a new technology like XML+CSS to build web pages has no future at all.

If you are interested in getting the most of XML for B2B, take a look to SOAP. It isn't very popular but I think it will be very useful in a few months.

Well, these are all good points. And, in my humble opinion the most powerful benefit is sharing data.

But, something all webmasters can appreciate. Separating web content, design and definitions. Here is how I put my sites together. A template that determines how the site will look, a site definition file that contains variables for colors, fonts, etc. and then xml documents that contain the content.

This way, to give your site a new look, or change the bgcolor in a table, you only edit one file and the entire site is updated. This is a very powerful concept. I have been doing this for years, and it really pays off.

It makes maintaining and redesigning a site a breeze.

:-)
--Ken

That in the above regard, you're using XML as a poor-mans database?

Basically from what I gather, XML is nothing more then a means of standardizing data into a file (like a more advanced flat file database).

Here's an example I'm throwing out (no experience with XML) - I have news on my site which is stored in a SQL database, and on my site the news is grabbed using PHP. However, I want to allow other websites to use my news, but because they don't have access to my database, and might not use PHP, I'll create a PHP script which will generate an XML file (or act as an XML file), a file that other sites can grab and then parse using any language they want (php, asp, cfml, perl).

Now you could have a script generate a tab deliminated flat file database, but the sites trying to grab the news wouldn't know what fields are what - but XML's formatting allows any Joe Blow to easily tell what is what (this is the headline, this is the the category, etc.)

Am I right?

What you have described is also known as RDF (look for slashdot or devshed RDF and you'll see an example of this).

Hello guys,

I also am have little confusion with the real purpose of XML in data exchange. I haven't use XML so pls. pardon my questions too.

I would first ask: is there any standard names in XML much like we understand <TABLE><TR><TD></TD></TR></TABLE> is a tag for table and it cannot be altered by anyone in order to generate tables.

and the next thing is that

with the sample posted above, couldn't it be written also as:


Name,OrderFrom,NumberofCopies

these could be data delimited with commas which can later be imported to a db, with the label of course.

If it can, then my question would be is it efficient to use XML compared with this one?

regards,


redshadow

To the first question, you have to see that HTML can be interpreted as a product of XML. You can define whichever tag you want. You can put as many attributes as you want. You can do everything you want, but only following one rule. Well-formed.

Well formed means that a tag can, either have an opening and closing tag (<tag></tag>) or be a self-closed (<tag />). You can learn more from the devshed's docs.

If you are asking for defined tags, there is only one defined tag in XML, and it is <?xml>.

As it is quite unuseful, people developed and "standarized" some XML "templates" (really called DTDs), like RDF. Look for it in the web and you'll see its possibilities. It is a defined framework where there are a lot of defined tags. It is hard to understand, though.

And apropos the second question, you are right. The way you propose is the most efficient one. You save bandwith, it is easy to process. And you can use it among a lot of servers.

But there would arrive one day in which you'll like to have another field, for example "format". And that field only should contain the values ("DVD", "VHS", "VCD") and no more. Do you think it's easy to upgrade the full system?

You'll have to define a new "protocol", to change the parsers, the queries, and you can be sure that most of the other servers will not update their clients, so your main application would spend half of the time returning "Bad request". Only because you wanted to add one tag.

In the XML case, you could add the "format" definition in the DTD and assing a default value of DVD. This way, when some of the clients ask for a movie, if they say nothing it would be in DVD (in fact, that's what ISellDVDs.com was selling). But if they specify it, it should use the new format. As clients I am referring to "server clients", like ISellDVDs against the main Paramount Server.

So you have to choose between high-efficiency and easy-extensibility.

But there are other techniques to improve efficiency, like compression. As XML is text (or your example), it would compress perfectly for high volumes of data.

I know this thread is getting long, but I have two cents over

I think the confusion around XML is simple. People think xml and HTML somehow is related.
And well, they are related in the form that HTML is not a programming language, it's basicly tags for to controll appearance of text and images.
XML is not a programming language, it is tags to controll how data is presented to whatever is going to use it. See the difference? HTML - Visual design, XML - Data design. Simplified that will do as explination. Sure XML tags aren't pre-deffined like HTML and other similar differances, but the main one is data vs visual.

Now, the power of XML is as simple as that, it makes data presentable in a specified format. Which means, everything that understands XML can make use of the data (C/C++, PHP, ASP, Java, JavaScript, Pearl and so on).

Lets take a theoretical example that doesn't deal with B2B solutions, or even different servers. This is within a single company.

Let's say we have an intranet, we actually sit and code the programs that we use in this business.
So we make a nice "Word97"-like program for the secretaries in C++, and maybe some Excel-like program for the salespeople in C. And we make a nice Java program for the people knocking on doors selling our amazing product. We allso have a webbsite where we sell our product using Perl, PHP, .NET, and ASP pages

We want all or some of the data to be interchangeble. We want to put some of the stuff that the secretaries do on the website, we want some of the salesdepartment stuff to be avalible to the ones knocking doors and we want to be able to process orders from borth the doorknockers and the website. Oh, and let's not forget we want statistiks... everyone loves statistiks.

Now, it would be a real pain to get all this to work, even with XML. But XML would make it alot easyer. We just let the programs output to XML and then bring it together at the end where we want the information to pop up.

Basicly, we could throw whatever we wanted into the mix here, like CAD, movies, whatver, becous all aplications now speak the same language data-wize, namely XML, eventhough they are coded in different programming languages. The programs must support the file formats for CAD and movies ofcourse, but you get the point I hope.

Basicly, XML does to data what HTML did for the web. We surf the web using Opera, Lynx, Netscape, IE and NeoPlanet, all reading HTML files, but programmed differently. This is acomplished becous HTML is the "languange" all browsers speak... or rather, understands...well, some understand more than others

Lastly, I agree that XML isn't and never will be a replacement of HTML, it isn't the purpose of it either in my opinion.

I agree that fundemental issues are normally poorly explained. In my mind, when you're learning anything, you can consider it as a mountain, the foot of which contains the simplest and most meaningful fundemental ideas which are the foundation of all else, the tip being the simplest final implementation of those ideas i.e. "hello world".

so what do most programming books start with, a hello world script, which we all understand is useful specifically (make sure everythings working, feel warm and fuzzy), but in a broader sense I think it's starting at the wrong end, the tip of the mountain instead of the base.

case in point, I have a book entitled "web application development in php4.0", it is for professionals who want to hone their methods and mindset. the first paragraph reads, "To truly master a language, it's crucial to understand not just the syntax and semantics of the language, but it's philosophy, background, and design characteristics." I think these are the first things that should be learned, not the last.

I'm sure there are countless intermediate developers who have languages listed in their resume that the don't even know the basic purpose of.

A computer tech friend of mine when giving an apraisal of XP said, "yah, well it's great with that XML backend", and didn't have a clue what that meant.. he just had some emotional idea of what xml meant, a solution to some range of complications. Maybe xml parsed interspousal communications would lead to a lesser divorce rate.

xml is data labelling, which makes data much more useful, versatile, and thus, valuable. at it's lowest quasi-legible form, any data you're likely dealing with is an ascii character.. but ascii characters floating around are basically meaningless. jump a couple notches to a sentance, a sentance on it's own, unless an Eastern proverb, is basically meaningless.. fast forward: almost all content is meaningless outside it's intended context and format, enter xml, all data becomes universally meaningful. xml is information about information, most basically, which you can't appreciate without a broad perspective of the internet or when transferring information two and fro many essentially autonomous functions. but to harken to the classic recipe example, even if on your grandma's geocities site, her cookie recipe is placed in xml, then it becomes a universal treat in a constant context rather than a fairly random association of words such as "bitter... heat.. steal.. turn.. 20mins.."

So, an example of what I intend on using xml for:

on a site I am building, I am thinking of using jabber server for all sorts of interuser communication, it's an IM server relaying IM's user - user according to username. so, when user_bob sends information to user_bella, it could be anything, a chess move in a chess game, a basic instant message, a command to make his avatar walk and kiss her avatar, etc, you can imagine.. so I have to offer some differentiation as to how they will be processed, with xml;

<chess move>j1 to k2</chess move>
or <action><option=french>kiss</option></action>

these would be created by user_bob's client and rendered by user_bella's client, which in both cases is actually the website with them logged in.

Hope this is a good example.. another example, in "profiles" rather than having 20 database calls for each field, sex, height, picture, name, etc.. I could have one call to "profile.xml" from the profile field of the user_bob row, which can act as a sub-database, (database: organized storage of information) reading:

<sex>male</sex>
<height>6 foot</height>

and then, not only is that information and format more useful to me, but it is also universally meaningful and distributable without offering any special access, as someone else noted. I can still edit or display merely the <sex> sub-field.

lastly, as in e-commerce, if all canon xl1 prosumer dv cams were xml labelled

<camcorder>
<brand>canon</brand>
<model>xl1</model>
<description>prosumer dv cam</description>
<price>$3500</price>
</camcorder>

then we would have an omniscient, omnipotent, inate price comparrison ability.

Hope that makes sense. this is of course before I've read the "Professional XML" book sitting on my shelf, maybe i'll have something better to contribute after that.

in response to the post before me which I just read, which is great;

I would describe xml as extensible, html as standardized, and thus xml having extensible and unlimited usage. xml could also be used for visual fomatting, but also all else. whereas html is rendered by the browser according to it's understanding, xml could be rendered according to my standards within a flash movie for instance.

xml is concerned with shifting data around. In comparison to HTML you are sending the data and the formatting therefore the advantage is you are cutting down the bandwidth - which obviously reduces costs and saves time.

First off, this is a great thread. Thanks to all who contributed.

Next, I was feeling rather disappointed because I didn't walk away after reading this with a clear understanding of where XML fits in to my world. I've got this stubborn idea in the back of my skull that has been issuing sarcastic remarks after every post I read like "Yeah, so what, I can do that in VBScript" or "Big whoop... ODBC can do that too, and you already know it...". I guess what I've finally discovered though is that even though I'm sure I can come up with a way to do almost anything without using XML, XML makes it all a lot easier.

For example, we host health news headlines on our site. The headlines originate from an outside vendor that we pay in order to access their content. They create a special site that is updated daily from which we can "scrape" their content for use on our site. I've built a Python program that downloads their page & saves it to disk. Then a separate VBScript program opens the saved file, parses it for the headlines, and resaves the file. It works pretty well, but every time they change the format of their page I have to go and update my script.

However, If they simply gave us the headlines in an XML file, I would only need to rely on a single XML parsing script. And, chances are that I would never need to update my script even if they added 4000 new data fields so long as they never changed their original data fields.

So, it kind of goes like this:
"(Almost) Anything you can do in (insert multiple acronyms here) can be done easier in XML."

Now, if I can only put this into practice...

I have been doing some reading as well on XML, because every job posting I find has it in there.

I think XML would be very useful for making information accessible to several agents/ scripts.

Lets say for example I create an XML page that has a result set of a bunch of users..I could then use that XML page to read into a Flash actionscript page, a PHP page, ASP, or any other page written in a language with XML support. It basically makes information platform and software independant.

Lets say I write a software package in PHP, and I would like to create scripts for different businesses to access some results of my software. If my software results are XML pages, then no matter what the business is using, ASP, JSP, PHP, whatever, they can utilize the information created from my product. Right?

I think. This is all from reading, not from doing, but I am thinking about it alot. But the concept of having information accessible across platforms and languages is a cool one. But I do think it would only be "useful" if you ARE ion a situation where several different platforms would need to access information from one source.

I haven't really needed xml before but i've just found a great use thanks to Fireworks MX.

With an xml file - you can create similar graphics using text drawn from the xml file.

Go here to see a simple tutorial:

http://www.macromedia.com/devnet/mx...icles/ddgw.html

I generated the xml file from Microsoft access - although i didn't have the correct version of access i found a useful tool here to generate the xml file from my access (mdb file)

http://rustemsoft.com/download1.htm

Apparently Access 2002 you can generate xml files.