XML - Purpose?

I’ve just started using XML, and finding it very useful. I have just installed NS after a year-and-a-half of programming my site in IE.

The biggest problem I found with NS is inability to import more than 1 external JS file.

I used an external JS file for all pages for the common content. I also used an external JS depending on the subfolder it was in, to do the functions common to the subfolder.

All of the external JS files apply some text, so if I put all of these JS files into 1, it would be huge, and it would load text not relevant to the page. By using XML I can load large text variables only when needed, thus keeping the main controlling JS to a minimum.

As these variables are easy to save,find and read it is easier to update than trying to go through a large JS file.

I am having a problem with NS though, if anyone can help me out…


In NS I get “xmlDoc.childNodes[i].childNodes[2] has no properties”
how do I rectify this?

I think that if you don’t mind losing a lot of your audience, XML is a nice way to be a picky programmer on your pages. :wink:

Since I don’t have access to the server logs (I’m using a free webhost), I modified this script (http://www.brinkster.com/CodeBank/ShowSnippet.aspx?n895) to monitor my website’s traffic.
XML can be handy after all. :wink:

XML is initially TEXT, it is not special in any manor, it is however the actual software, which makes XML. Essentially XML is a bloated ML(Markup Language), which has been part of it’s wide adoptance and support.
Although it can be greatly compressed, people have taken extensive measures to optimize XML, such as altering the parsing process to reduce overhead (As [i][u]MattR[/u][/i] quite rightly pointed out) and also fixating schemas within the parser as well as numerous [url=http://www.zapthink.com/flashes/10072002Flash.html][i][u]other techniques[/u][/i].
Due to a number of factors XML is essentially a good ‘thing’, which resolves many issues and I don’t mean just from the point of view of having a method to unify data exchange on numerous platforms, but also from a development point of view. Such as data collaboration and integration. Parsers already handle the processing of XML documents, so its more a method of integration than anything else [ < development time ].
The tools or utilities that make process & parse XML are/is what makes the hype for XML. This includes all the derivatives, such as XSLT, WSDL, SOAP(webservices) etc. By having a unified model for data, you can enrich the way you use your data by invoking commonly used tools and functions in the way you present it.

Any way for a further datailed evaluation on XML take a look at this white paper. ([url=http://www.zapthink.com/reports/proscons-view.html]http://www.zapthink.com/reports/proscons-view.html)

Quick Listing of Arguments
[color=#006699]Pro: XML is a structured text format[/color]
[color=#006699]Pro: XML is designed with the Internet in mind[/color]
[color=#006699]Pro: XML processing technology is widespread, easily available, and cheap[/color]
[color=#006699]Pro: XML is Human-Readable[/color]
[color=#006699]Pro: XML is very flexible – you can define other languages with XML[/color]
[color=#006699]Pro: XML separates process from content[/color]
[color=#006699]Pro: XML documents can be validated using a Validating Parser[/color]
[color=#006699]Pro: XML systems are lower cost than other alternatives. They finally enable small and medium-sized organizations to participate.[/color]
[color=#006699]Pro: XML is open. It is influenced by a number of standards organizations[/color]
[color=#006699]Pro: Agreement on a common DTD or Schema results in exchangeable documents[/color]
[color=#006699]Pro: There are an increasing number of individuals with XML skills.[/color]
[color=#006699]Pro: Business and technical management positively view XML technologies.[/color]
[color=#006699]Pro: XML can leverage existing security solutions.[/color]
[color=#006699]Pro: XML is license-free, platform-neutral, and widely supported[/color]
[color=#006699]Pro: XML can be viewed with simple tools such as browsers[/color]
[color=#006699]Pro: XML supports complicated and focused searching needs[/color]
[color=#006699]Pro: XML enables e-Business[/color]
[color=#006699]Pro: XML is easily internationalized.[/color]
[color=#006699]Pro: The Time is Right.[/color]
[color=#006699]Con: XML is a space, processor, and bandwidth hog[/color]
[color=#006699]Con: XML is just a document, not a programming language or a solution for world peace.[/color]
[color=#006699]Con: If XML is so similar to HTML and SGML, why aren’t those languages sufficient? [/color]
[color=#006699]Con: Every XML format can become a “proprietary” XML format[/color]
[color=#006699]Con: XML is great for text, but awful for binary data[/color]
[color=#006699]Con: XML is a regression from centralized, efficient database systems to inefficient file processing[/color]
[color=#006699]Con: XML specifications are not yet complete or tested[/color]
[color=#006699]Con: XML DTDs are insufficient for most business and industrial-strength applications, and XML Schema is too complex[/color]
[color=#006699]Con: XML will never completely replace other technologies, like EDI.[/color]

Hope that clears up some issues anyway.

There is significant con XML documents here:

I could be mistaken for a bit of an XML evangelist in some circles but I think MattR’s statement above is the most accurate/simplest summary of the technology.

I’m more of a standards evangelist more than an evangelist for a particular technology. This is because I’m fundamentally a lazy programmer. Programming technologies change so often, it’s a lot of hard work keeping up. Any widespread adoption of a standard means less work for me :slight_smile:
For instance, templating systems. Somewhere on this forum is a reeeeeaaaally long thread on counting them all up. I’m too lazy to learn a new templating system for every CMS or Portal that comes along so I restrict my choices to one that uses XSLT. Why? …because it’s a standard :slight_smile:

How good or bad the implementation is done is almost irrelevent.

So, the big revolution for the internet is not the XML technology itself, it’s the mere fact that everyone agreed on something for once. Less work for us, cheaper for our clients, more opportunities to share information (as well as data).

Just curious why you revived this thread, what was you looking for Tezza?
Again i’m an evangelist as you put, but I know where the advantages and disadvantages begin. XML is bloated, i’m not going to deny that, but the flexibility it provides is its strength and one of its initial goals. The more the statement of performance arises the more it deminishes with new technology. I don’t believe “because XML is a standard” is a valid reason to use XML, as its irrelevant, if it’s performace, I certainly wouldn’t use XML, The right reasons, the right choices, will lead to a suitable application. Not because its standard…

I think this thread will always be relevent as long as XML is around. I happened to trip over it while searching for something else XML related.

I think any technology is horses for courses. You should probably pick your technology on a per-project/per-needs basis. In general though, I always gravitate to standards based solutions because of the aformentioned advantages.

For example, a high-performance application such as a computer game may not have a great need to exchange data in an interoperable way - so XML is unlikely to be suitable. On the other hand, an application such as a portal/CMS is sure to benefit from a standard based implementation because interoperability and maintanence and functional scalablity is important. So in this case, the trade off in performance is likely to be justified.

XML is no silver bullet. It’s a horse for a particular course. And since this forum is generally about web scripting (the environment XML was designed for), it’s full of courses for this horse.

resons for re-inventing solutions that XML standards solve need to be VERY compelling to warrent their usage while XML is readily available in this space.

I’m pleased to read that I’m not the only one to recognize and observe that the XML emporer has no clothes. That is, XML itself is a text formatting discipline, nothing more or less. I happen to like this kind of discipline.

I’ve observed over the last five years that XML has evolved to mean two things: 1) it’s heritage as a formatting standard, inherited from SGML, which is what programmers are interested in. 2) XML as a business tool/buzzword. This latter implies XML’s use in web services, RSS feeds, integrity in forming business documents, and all the rest, which transcend the mere technicalities. An analogy would be the difference between how a wrench is made, its steel composition, forging process, and final finishing vs. the work that can be performed by that wrench and how much money can be made by having it and a trained mechanic using it effectively.

I’ve found that when I speak with non-technical types who refer to XML, it is clearly this latter that is implied. When I’m asked if I’m “familiar with” XML, they’re asking if I’ve implemented XML as a business solution. They recognize the business value of having a platform-neutral way to share and access data.

Programmers look at XML and shake their heads, asking: “so, what’s the big deal?” I agree with this (see my opening comment), but you have to look past that and understand the value and significance of a standard such as XML. Go back 15-20 years to the EDI wars to see how significant the lack of agreed-upon communication standards was. Go back even ten years to see how vendor-specific the COM model was. Having been there for both of these (and more), I can tell you that having XML as a given would have removed the focus on bits and bytes, and directed that focus on higher-level issues where it belonged.

Even though I’m a little late still have to chime in on this one.

Like it has been said before, XML by itself is really nothing special. It has been standards adoption that make everything work. All you have to do is have a look at this http://xml.coverpages.org/ni2004-08-03-a.html, at the bottom of the page where it lists different protocols for different specialties in the financial sector.

Yes MS is using it for everything now. MSN Messenger, MS Office 2003, and so on. Macromedia uses it on the backend of their apps as well. Auto-complete in DW MX 2004 is based on one. If per chance you do need to create XML data that corresponds to a schema and are working largely with non-technical contributors, Excel 2003 Pro makes life a whole lot easier. Just avoid the <position> tag. Really makes it bug out.

Another nice thing about it is on the corporate side, it can pass through firewalls easily. Especially important if you have a corporate service delivered by XML :wink:

Now I’m not saying its the next coming or anything like that, and at times buzzwords get thrown around a lot. But the concept behind XML, standardized, lightweight access to data, really has a lot going for it.

I’ve just recently discovered the implications of XML/XSL combination myself and would like to contribute to this discussion. Here’s the big “draw” for me. Consider the following:

When using PHP to get data from a mysql database, and format that data using flatfile templates, php function based templates, or database stored templates, there is a certain amount of PHP code required to make it happen, and innevitably the output is a rather large html (or xhtml) page.

Now consider this:

By creating php files that output xml data only, ensuring that the xml output has a xsl stylesheet specified as well as a custom dtd, you drastically reduce the amount of work your php app has to do. Because the xsl and dtd are both cachable documents and are only downloaded again if required, or implicity asked for, the php files no longer require any templating code or have to worry about the order in which data is read out to the client. All the php file has to do is gather cookie, session, form and request data, santize and validate it, determine what is to be done with it (commit data or get data), then construct an xml output buffer based on the dtd for your app. It then writes that to the screen, where the browser consumes it and caches the xsl (templating machanism) and the dtd (validation mechanism). Since all but the raw data is now cachable, and all your app has to send is xml data, your server CP usage and bandwidth is next to nil. The client does the templating and if the master xsl or dtd ever changes, the browser will get the fresh copy.

That’s a HUGE advantage over html output.