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…
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 optimizeXML, 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.
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
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
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
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.
