Forum Moderators: open
Hope that made sense?
Cheers
In the context of the www (and not any back office or in-house company solutions), what is the benefit in using XML if it cannot be seen by Netscape 4 and AOL browsers?
Surely the benefits are outweighed if twin versions of pages have to be constructed for the other non xml parser browsers.
Am I missing something here?
How come there is so much demand for XML skills for the www, when pages made with it can't be recognised by a significant chunk of web users? Not everyone is using IE 5/+ or NN6.
If data transfer is the main benefit, we have perfect solutions already in CGI and other languages.
Is it because there is a Java (or other) server-side solution which presents data to all users as hard coded html?
Anyone enlighten me?
I'm fuzzy on this, too, but I believe you're close when you say "other server-side solution". The information from online xml forms would be identified (something like a field name) and that information could then be mapped directly into databases ranging from Oracle to MS Access, other forms, in-house accounting packages, etc.
I don't think that's the case. Web is just one "platform" for large companies, they are pursuing the lowest common denominator in data entry -not just web. Intranets of wholesalers might use xml encoded forms to patch their purchase orders through to manufacturers on the existing EDI networks (Electronic Data Interface, I think).
Browsers do happen to be be a good front end for data entry, though. They're still liteweight on some of the field and record handling/manipulation features -from what I've read- xml seems to be an attempt to address that.
yanton, from what I've read, your question nails it -- this is exactly the pivot point. Without very wide browser support, XML will stay in back office and specific B2B applications but it won't make it to the www in general.
So why would browser developers support XML? Well, if it becomes a standard, XML would allow for much simpler browsers, for one.
With HTML there is a chaotic mix of kinds of tags that the browser must interpret (forms tags, table tags, top level tags, block level tags, character level tags, etc.) That job significantly fattens up the brower code.
If XML became standard, it would also make possible much more efficient search engines and specific document retrieval utilities. When I think of the HTML tags that almost never get used -- tags like <cite>, <dfn>, <address> and so on -- I get a feel for what could be possible.
Here is the first [webreference.com] of a series of 27 columns on XML from Webreference. Nicely informative without being overly academic.
Of course, XML is catching on rapidly for non-web applications. Why build your own file formats when XML can do the job? It can make a lot of interoperation problems smaller than they've been in the past. This seems to be the big hotspot right now.
So, weighing xml in the balance in the context only of the web, it seems that if the extra functionality which xml offers, outweighs the loss of 20% of users (which may need suitable mirror pages to cater for their browsers) then it may well be worth the extra effort involved. The 20% would also shrink over time as users upgrade to xml parser enabled browsers.
Maybe it's time to start learning the lingo.
One of the nice aspects of XML, is that you can mix multiple specs in one file... e.g., XHTML 1.0 and SVG 1.0. Once neat stuff like SVG begins to appear (probably in 6.5 for Netscape, dunno about IE), you can mix in a few of those, hopefully without too many incompatibilities on older browsers. That sort of mix-and-match stuff is what makes SVG nicer than Flash.
[nypl.org ]