I WANT- a painless way to bring in external text?

[Bill Posters]

I would like to add a (relatively) small events listings to my folio site.
I'm thinking anywhere between 10-30 events each including date, title (possibly as a link), address and one or two lines of blurb.

I'm hoping I can find a way of doing this whilst storing the raw info in a simple txt file or filemaker file (or equiv).

I would like to do this without relying on server-side methods or steep learning curves for new technologies.

"Includes" sounds to be the right kinda thing, but again I'm not looking to stick a back-end on my site. I want to keep it really simple.
XML also has the right kinda ring to it.

Server-side access (i.e. installing db stuff) is almost certainly not an option.

I would like to somehow draw in the text from an external text file.
I would like to be able to simply swap/update the text file and have the diary listings reflect the changes.

That being said, I would rather hard-code the updates than get my brain stuck into MySQL et al (my head's not in that place), but would ideally rather find a real no-brainer way of handling it so I don't have to hard-code it.
The site is my folly, so the moment something requires a sudden spike in the learning curve is the moment it dies for me.

I don't mind getting my head round creating a simple db file, but I'm hoping I can involve its contents without messing round with back-end stuff.
Javascript is not an option either.

Is there a way I can get what I want?

TIA

p.s. in case it hasn't come across here, I know NOTHING about stuff like PHP, XML, DBs, blah blah

[Karloff]

As long as you dont wish to process the contents of your TXT file, you can use SSI (Server Side Includes). You can use SSI with Apache or IIS and many more web servers, so there shouldn't be any moving problems later. A simple Apache and SSI tutorial is here.

Now don't shout at me for suggesting a server-side solution that sounds like a new language. Honestly, I cannot think of an easier way to do it without using PHP, Perl, or ASP, a DB of some sort or JavaScript - basically you ruled out all the standard aproaches upfront [img]images/smilies/rolleyes.gif[/img] . SSI is just a few very simple directives and if you know HTML you will easilly get to terms with SSI. And no, using SSI isn't really sticking a backend to your site. Actually not at all, methinks.

You mentioned XML, and I would dearly recommed it as you are talking about 30 something events here - no need for a DB. However, you won't be able to manipulate/extract the data from your XML without resolving to some XML DOM and possibly XSLT coding. If you want XML, as it is ideal, and are using ASP on the server or can rely on Moz and IE, simply say so and I would gladly get you started with an example in context to your problem.

Last but not least, if you really want to avoid all these solutions, why not make an HTML template that you will use to update your events listings everytime? I mean, you did say I don't mind getting my head round creating a simple db file so why not create a simple HTML file each time and forget about SSI, XML, and the rest? Just a thought [img]images/smilies/biggrin.gif[/img]

[Bill Posters]

I've been taking a look around and I'm now of the opinion that XML is the way to go.
Read the INtro to XML article at SitePoint.com, but it wasn't as enlightening as it seemed to think it was.

After one or two blind turns I ended up (back) at W3Schools.com (ol' faithful) which appears to have a very well organised bunch of references and tutorials for all levels of understanding from XML guru right down to Bill 'Wah?' Posters.


I'll bury my nose in those for a weekend and see if I can solve the problem with a little bit of joined up thinking.


If I hit a brick wall I'll be sure to give you a tap on the shoulder.

[Bill Posters]

Actually, before I get stuck in, is there anything I should know about xml that might make it inappropriate for my needs (browser support, etc...)?
I'm aiming for IE5+, Moz1/NN6/equiv, basically W3C compliant browsers and up.

I like the look of the 'data islands' approach, so that'll be the first thing I'll be trying.

Cheers (again)

[Technosailor]

XML is server side. It dfoes not matter what browser the clientside is using. Now the way you return the data to the browser is another matter.

FWIW, XML for all intents and purposes IS a database. It stores data and is not conernced with how the data is used.

Aaron

[Bill Posters]

Server-side? But... but...

Some of the examples I've been looking at appear to handle it much like external css.
The xml doc is linked into the html doc and ided spans and proprietory tags are used to bring sectioned content into the html page during pageload.

Or so it seems.


So far, I've not seen any mention of the need for server-side bouncing.
What have I misunderstood?

[Technosailor]

Maybe you can link to examples so I can see it? I don't claim to be an expert in xML as I've only implemented it once, but I do have a good theoretical understanding of the uses.

You can have XML in HTML. Parsing it (reliably) is another thing. You might be able to do it with javascript but I don't really know.

[Technosailor]

Check this out...
http://www.developersdex.com/gurus/articles/166.asp

[Bill Posters]

Read the article, but not sure how it was meant to help.
It spoke of things I know nothing about, but other than the title of the article it appeared to chunder on about naltascript which is presumably neither client-side or well-supported.

Perhaps I'm coming from a completely new angle to this issue (i.e. UTTER know-nothing), but is there really no simple method for including external data in an html page that can run locally as well as remotely (i.e. client-side)?


The way I've been reading it, xml is a client-sdie process which (as said before) bears a similar realtionship to the html markup as css and other client-side external add-ons.

Sketch, can you give me a url where it explains categorically that xml is server-side?

I'm getting more than a little confused. :\


btw, the examples I'm speaking of are those at W3Schools XML tutorials.
http://www.w3schools.com/xml/xml_examples.asp

Maybe what I'm seeing on screen is not how it should be. I dunno.

On this page I get this:


I look at that and I'm wondering where the actual artist/album details are.

[Technosailor]

yeah perhaps I should clarify. After scanning the w3 xml docs I think I understand your confusion over what I'mn saying.

The key is this: XML is data, it is not implementation. It is markup.

How you get the data to the browser, the transport, is where I think you're tripping up.

Let's use a more familiar analogy. You can have a link on a site open with javascript or as html. Either one results in the same thing - an open window with a site being loaded. In this analogy, the page to be loaded is your XML. How that site is opened is not the concern of the site being opened. It is the concern of the page doing the openeing that is using the link.

Likewise, XML doesn't care how the data is used. An XML doc can be processed via PHP, ASP, C#, Python, and even javascript. These languages are the transport to get the data from the document to the browser for the user to see.

Having said that, it is more reliable to do this stuff server side. It's ALWAYS best to do things serverside when the choice is available. The server platform is uniform. The client platform is not. However, you CAN parse XML with javascript. You run into all the same kinds of browser and OS issues when parsing XML with javascript as you would doing anything else in javascript.

If you're going to ask me how to do it, let me save you some energy. I have no idea. If I parse XML, it's with PHP because PHP can then return the parsed data to the browser in standard format.

Sorry couldn't be of more help.
Aaron

[Bill Posters]

I would consider using javascript to parse the xml, but I get the idea it would make the final markup/code even more bulky and I'm trying to keep the html itself slim and sexy.

I was also trying to keep javascript out of the essential content (gotta break the habit somehow)

I'll take a look at the javascript options for implementation and see if it's simple enough and effective enough to make it a requirement of site viewing.

If not, then *and only then* will I take a look at the server-sdie options. SS is a habit I was hoping to avoid*
as for me it is unlikely to find any other uses than on my own site.
(generally as I'm actually moving away from web-design towards my core interests of print and painting)

Thx for the help so far Sketch and Karloff.

At the end of the day (or rather, until I get my head round the alternatives) I guess hard-coding the data in isn't gonna kill me.
It's only gonna be around 30 or so events updated every two weeks.

[Karloff]

XML is server side. It dfoes not matter what browser the clientside is using. Now the way you return the data to the browser is another matter.

Hmm... XML is not server side only! If an XML document is processed on the server and transformed in one way or the other, though most likely using XSL, it can be returned to a client according to the clients specific requirements. Thus, if you have any IE 5.5+ you can instruct the final processing to use an advanced XSLT template with nifty IE specifica or you could even leave the XML display processing to the client itself as IE 5+ (more specifically MSXML 3.x onwards) has fine support of the latest W3C XML standards. If, however, the client is Mozilla based, you could churn out a XUL document. If it is a mobile, simply use your WML XSLT stylesheet et voila. And so on and so forth. Even if the client is not a visual device, say another remote server application, you can process the XML accordingly for that application.

FWIW, XML for all intents and purposes IS a database. It stores data and is not conernced with how the data is used.

XML is not a database! It is no more than a document containing well-formed, structured information with an extremely flexible semantics. Having said that XML is not a database, you can certainly develop an IMDB (In Memory Database) which, if optimized, can perform supremely for XPath based fulkl-text searching or similar tasks. XML is also used, and most frequently so, as a data interchange format for enabling inter-operability or consolidating databases, other proprietary document formats and applications. There is even fully native XML databases such as Tamino or TextML Server. Still, XML itself is a far cry from a database.

Now to manipulating XML documents where I shall concentrate on JavaScript as it has been mentioned in these threads often. JavaScript itself knows nothing of an XML, or HTML for that matter, document. What exposes the contents of an XML document is its DOM (Document Object Model). I think the general misconception about JavaScript being able to maipulate XML or HTML has come with DHTML which is often thought of as HTML and JavaScript only, the HTML-DOM being completely forgotten. The HTML-DOM provides a standard programming model for working with HTML as is described by W3C. The DOM provides a standard to programmatically navigate - or even create/update/transform - the contents of HTML documents and as such, is a set of language neutral APIs (Application Programming Interfaces). Not only is it language neutral, it is also vendor neutral which is why there is dozens of parser implementations. Exactly the same goes for XML. So when you are manipulating XML via JavaScript you are merely using JavaScript to programmatically access the APIs that, say MSXML - the MS parser used by Windows apps, exposes. While some vendors choose to implement additional features to their parsers, or leave out some recommended features, you can still program relatively cross-parser safe as long as your platform supports some kind of parser and that parser supports a greater deal of the W3C recommedations.

On the server you wouldn't run into such problems as it is a completely controlled environment. On the client, you could run into problems for many reasons, but least of all because of JavaScript. The main problem on the client is whether it has an XML parser. IE 5+ and Mozilla clones have one, and surprsingly enough, they are fairly compatible! Other, more exotic, browsers or clients might completely lack one and can thus, not interprate XML. JavaScript won't help you alot if the browser doesn't expose the parsers APIs to the language itself unless you write a simple and slow parser yourself in pure JavaScript (rather silly to do :-P ).

Actually, before I get stuck in, is there anything I should know about xml that might make it inappropriate for my needs (browser support, etc...)?
I'm aiming for IE5+, Moz1/NN6/equiv, basically W3C compliant browsers and up.

Enough rethoric on the fundamentals now :D You say you are aiming at IE 5+ and Mozilla clones. To be safe, go with the lowest common denominator of parsers that both use. For IE 5.01 on Windows 2000, that would be MSXML 2.5 - since MSXML 3 you could only upgrade via a seperate distribution though Win XP does offer the newest release of MSXML 4 (also referred to as MS XML Core Services). Sadly, this makes client side XML processing a bit shaky on IE unless you only use 2.5 features. It is sad because MSXML 3 has been a huge leap for the processor and version 4 is just a charm to say the least! Fortunately, you can degrade gracefully by siffing out the version and/or implementing only cross-version safe features etc. Mozilla has the XML Extras which also offer the XML Parser as well as the XSLT module which is implemented in TransforMiix. Either way, there is a bit less version confusion than with MS.

Now for the real solution as long as you stick to the aforementioned browsers: use XML for your events list, XSLT to transform it nicely on the client to HTML, and CSS to style the HTML neatly. Sounds like a lot, but it isn't and your markup/code wont be bulky and you don't even need JavaScript. Will work on IE and Mozilla though I did only test it on IE6 (with MSXML 4) and Mozilla 1.3 (sorry about that, but I develop for Intranets/Extranets and other types of controlled client environements so I dont have the older stuff at home to test against). Woohoo :D

p.s. you could skip the XSLT completely and simply bind the XML to a CSS, but that is a far from recommended.

Here is an example of a events type of page

events.xml

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="events.xsl"?>
<events>
 <event>
  <name>Lunch Box Memories</name>
  <description>Exhibition of lunch boxes from 1956 to 1985 by various collectors across the country.</description>
  <organizer>Headley-Whitney Museum</organizer>
  <location>Lexington, KY</location>
  <date>8. April 2003</date>
  <time>13:30 - 17:00</time>
  <source>http://www.headley-whitney.org/</source>
 </event>
 <event>
  <name>Young Americanos</name>
  <description>An exhibition of works from aspiring Mexican artists living in the U.S.A.</description>
  <organizer>Mexican Heritage Plaza</organizer>
  <location>San Jose, CA</location>
  <date>10. April 2003</date>
  <time>13:30 - 17:00</time>
  <source>http://www.mhcviva.org/</source>
 </event>
 <event>
  <name>A Communion of the Spirits</name>
  <description>A 25-Year Study of the World of African-American Quilters and the Documentary Process</description>
  <organizer>Historical Society of Western Pennsylvania Programming</organizer>
  <location>Pittsburgh, PA</location>
  <date>11. April 2003</date>
  <time>All day</time>
  <source>http://www.pghhistory.org/</source>
 </event>
 <event>
  <name>My Story: A Gordon Snidow Retrospective</name>
  <description>An exhibition of autobiographical works by Gordon Snidow.</description>
  <organizer>The Hubbard Museum of the American West</organizer>
  <location>Washington, DC</location>
  <date>17. April 2003</date>
  <time>10:00 - 14:30</time>
  <source>http://www.hubbardmuseum.com/</source>
 </event>
 <event>
  <name>Creativity and Resistance: Maroon Cultures in the Americas</name>
  <description>On display is a vast collection of Maroon art and literature depicting their cultural struggle over decades.</description>
  <organizer>International Storytelling Center</organizer>
  <location>Jonesborough, TN</location>
  <date>20. April 2003</date>
  <time>08:00 - 19:00</time>
  <source>http://www.storytellingcenter.com/</source>
 </event>
 <event>
  <name>Exploring Garden Transformations 1900-2000, American Garden Legacy Series</name>
  <description>A beautifully enchanting display of photographs showing the art of garden landscape decoration.</description>
  <organizer>Anniston Museum of Natural History</organizer>
  <location>Anniston, AL</location>
  <date>24. April 2003</date>
  <time>All day</time>
  <source>http://www.annistonmuseum.org/</source>
 </event>
</events>

events.xsl

<?xml version='1.0'?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="html" />
<xsl:template match="/">
<html>
<head>
<title>Events</title>
<style>
table.events {width: 600px;}
td.left-col {width: 120px;border: 1px solid #CCCCCC;}
td.right-col {background-color: #F7F7F7; border: 1px solid #CCCCCC; padding: 10px;}
h1 {font: bold 14pt Verdana; color: #333333; margin: 0px; margin-bottom: 5px; padding-bottom:5px; border-bottom: 1px solid #CCCCCC;}
p {font: 10pt Verdana; color: #333333; margin: 0px;}
p.date {font: bold 8pt Verdana; color: #FF6600; padding: 10px; background-color: #F7F7F7;}
p.time {font: 8pt Verdana; margin: 10px;}
p.name {font-weight: bold; color: #FF6600; margin-bottom: 5px; padding-bottom:5px; border-bottom: 1px solid #CCCCCC;}
p.description {margin-bottom: 10px;}
p.organizer {font-weight: bold;}
a.organizer, a.organizer:active {font: 9pt Verdana; color: #FF6600;}
a.organizer:hover {color: #CC3300}
</style>
</head>
<body>
<table class="events" border="0" cellpadding="0" cellspacing="10">
 <tr>
  <th colspan="2" align="left">
   <h1>Events</h1>
   <p>Event calendar of nationwide art exhibitions and literary readings, lectures and more.</p>
  </th>
 </tr>
<xsl:for-each select="//events/event">
 <tr>
  <td class="left-col" valign="top">
   <p class="date"><xsl:value-of select="date" /></p>
   <p class="time"><b>Times</b><br /><xsl:value-of select="time" /></p>
  </td>
  <td class="right-col" valign="top">
   <p class="name"><xsl:value-of select="name" /></p>
   <p class="description"><xsl:value-of select="description" /></p>
   <p class="organizer">Organizer: <a class="organizer">
   <xsl:attribute name="title">Link: <xsl:value-of select="organizer" /></xsl:attribute>
   <xsl:attribute name="href"><xsl:value-of select="source" /></xsl:attribute>
   <xsl:value-of select="organizer" />
   </a></p>
  </td>
 </tr>
</xsl:for-each>
</table>
</body>
</html>
</xsl:template>
</xsl:stylesheet>

Simply save both as mentioned above and open up events.xml in Internet Explorer or Mozilla. Should work! Of course, there is a lot more you could do with this if you introduce JavaScript/DOM like sorting by various attributes, searching etc. The beauty of this approach also lies in the simplicity to upgrade to a server side solution later where you would apply the XSLT template on the server side and send out pure HTML which could be shown to any browser. Note: the date and time implementation you see in this sample is quirky to say the least. Unfortunately there is only processor proprietary solutions (like XPath extensions) to handle standard data/time formatting. So I kept it stupid and simple :)

Don't believe me? Here is a simple ASP example

<%@ LANGUAGE="VBScript" %>
<%
Function LoadXMLSource( SourceName )
 Dim oXMLDoc
 Set oXMLDoc = Server.CreateObject( "MSXML2.FreeThreadedDOMDocument.4.0" )
 oXMLDoc.async = false
 oXMLDoc.load( SourceName )
 Set LoadXMLSource = oXMLDoc
 Set oXMLDoc = Nothing
End Function
Function GetProcessor( TransformName )
 Dim oXSLDoc
 Dim oXSLTemplate
 Dim oXSLProcessor
 Set oXSLDoc = Server.CreateObject("MSXML2.FreeThreadedDOMDocument.4.0")
 Set oXSLTemplate = Server.CreateObject("MSXML2.XSLTemplate.4.0")
 oXSLDoc.async = false
 oXSLDoc.load( TransformName )
 oXSLTemplate.stylesheet = oXSLDoc
 Set oXSLProcessor = oXSLTemplate.createProcessor()
 Set GetProcessor = oXSLProcessor
 Set oXSLDoc = Nothing
 Set oXSLTemplate = Nothing
 Set oXSLProcessor = Nothing
End Function
Function TransformData( SrcDoc, Processor )
 Processor.input  = SrcDoc
 Processor.output = Response
 Processor.transform()
End Function
Dim SrcDoc
Dim Processor
Set SrcDoc = LoadXMLSource( Server.MapPath( "events.xml" ) )
Set Processor = GetProcessor( Server.MapPath( "events.xsl" ) )
TransformData SrcDoc, Processor
%>

Only change you will need to make is to your XML document, namely, exclude (comment or delete) the line refering to the XSL:

<?xml-stylesheet type="text/xsl" href="events.xsl"?>

Well it might be only me, and my fascination if not love for XML related technologies, but I think this is really an easy and elegant aproach which is future proof as it can be extended in almost any way you might wish - not only with ASP that is. PHP or most other languages would be fine too.

Hope this cleared some misconceptions up, and could provide a nads on aproach to your problem. If you're still confused or do not wish to dabble around with XML technologies, as I must admit that it can get nasty pretty fast, then I would simply write pure HTML and edit that each time a new event is added.

Either way, happy coding and enjoy your artistic fututre (print & painting),

[Technosailor]

Karloff,

While I respect you and your obvious knowledge, I wish you would have read all of what I said. I started by sagying I thought XML was serverside only, acknowledging that I wasn't sure, and backtracekd later and gave JS it's due!

Secondly, I said in essence XML is a database, because in essence it is!!! It's not a RDBMS, but it maintains data!! That, in essence makes it a database.

Please, please read all of what I say before making me look like a blathering idiot.

Thanks.

Aaron

[Karloff]

Sketch,

I am sorry if I have, in any way, led you to perceive my answer that way. It most definately was not my intent to make your statements look false; instead I quoted some your statements to elaborate on the use of XML as I see fit. This in turn, not necessarilly meaning that my view about an XML document itself not being a database, or any other uses of XML standards have to be true.

Either way, I am sorry for any hard feelings!

[Technosailor]

no problem.

[Dr Livingston]

I would have to disagree about XML being a database - it is not.

A database is for storage and for reading/querying the stored data - you cannot do this with XML.

XML originally and still is a means of distribution to many/any document format that you care to throw at it through the use of an XSL stylesheet.

I sort of rest the case 8)

[MattR]

I would have to disagree about XML being a database - it is not.

A database is for storage and for reading/querying the stored data - you cannot do this with XML.

XML originally and still is a means of distribution to many/any document format that you care to throw at it through the use of an XSL stylesheet.

I sort of rest the case 8)

Without a definition of database it is hard to say whether XML can be called a database or not.

Dictionary.com calls a database 'a collection of data arranged for ease and speed of search and retrieval' and 'an organized body of related information'.

So, an XML document *could* be a database in exactly the same way a flat-ASCII comma-delimited (CSV) file would be. It is simply a bunch of data in a location that you can look at.

However when most people say 'database' they really mean 'database management system' -- a collection of functions/applications which allow you to securely retrieve and modify data *in* a database.

The idea that XML is a superior machine-to-machine data exchange format has been thoroughly debunked by Fabian Pascal at www.dbdebunk.com. He contends that once you agree on a standard (in XML parlance an XSD) that the physical data format (XML's hierarchical method) can be anything.

Mr. Pascal contends that as an exchange format XML is inherently inferior to many existing technologies. I wholeheartedly agree with him. XML is, by its tag and hierarchical nature, inefficient. I can store more data in less space with a CSV file than I can with XML.

http://www.dbazine.com/pascal9.html

Data exchange requires agreement on (a) what data is to be exchanged, and (b) its physical format, which are orthogonal (independent) considerations. Suppose, for example, that a personnel management system feeds data to a payroll system. For this to work, the two departments must agree on what personnel data is to be fed (say, name, position, seniority, and so on) and the physical format in which it will be transmitted (say, ASCII [comma] delimited).

Note very carefully that when they agree on the data, the departments actually agree on a common meaning of that data. This must be the case, because the agreement derives from their own systems, which contain the two departments' logical models, within which the data must fit. Note also that once the common meaning is agreed upon, the payroll system does not need to be told "what the data is" each time data is sent to it by the personnel system. Indeed, that's the point of the upfront agreement in the first place. Thus, given an agreed meaning, data exchange requires only a physical format which, as I mentioned, is orthogonal to meaning. Any format will do, as long as it is agreed upon. Now, the industry lacks many things, but format is hardly one of them; there is a plethora of physical formats (see conclusion on this point) to choose from. So why invent yet a new one?

The fad-driven computer industry, being told that XML was the cure to all the world’s problems, jumped on it and is coming out with everything from XSLT stylesheets to XML-powered kitchen appliances. The problem is that it is an inefficient solution to the problem.

Certainly there has been a lot of development in utility applications and libraries to manage and extend XML (XPATH, XSLT, etc.). This raises the value of XML because you, as the application developer, do not have to write libraries to change, search, convert to HTML, etc. XML documents.

Does this mean XML is superior? Of course not. Had developers put the same amount of effort in creating libraries to transform a CSV file into HTML as they did XML (and I contend it would have taken less time and effort) then you could just as easily, if not moreso, use a flat-file as a data source for your web application. It's just that the XML libraries are superior to, say, CSV libraries (since I doubt many exist).

So feel free to use XML and XSLT -- not because XML is superior, just that it happens to be in vogue now. Just know that if the computer industry follows past behavior they’re more than likely going to throw it all away in a few years and start over with the 'next best thing since sliced bread'.

[r937]

whoa, that fabian guy sure hates xml too, doesn't he

is there anything he does like, besides himself?

i'm sorry, but that's the attitutde that percolates through his writing -- all the emphasis, the thinly veiled sarcasm, the you're-all-nuts-and-i'm-not tone that filters through it all

i don't care if the guy's right or not, i cannot stomach him

rudy

[Karloff]

While I am nowhere near to being able to challenge Fabian Pascal's denounciation of XML as a data management technology, I do believe he has picked out one fad and elaborated too much on it for no other purpose than proving a rather obvious point (XML for data management is still infantile and has to prove itself if at all); admittedly in a pretty competent manner so to put the technology as a whole in a bad light.

However, comming from a different angle, and possibly the one of bandwagons, the "me-too's" and overnight "experts" who come out of the woodwork to make pronouncements on new fads, I have used XML technologies in just about every tier with great success. Ranging from XUL and XML-RPC to reduce intra- and extranet bandwidth usage of web applications considerably as well as perceived performance (contra to The Horror of XML statements on bandwidth usage and performance) to XML Schemas for defining RDBMS data models as I mention here.

To me XML and its slew of related standards is a saviour. And yes, most definately, the many utility applications and libraries have played the most important role in my consideration of XML et al. And no, I do not think it is a fad, an in vogue star amongst millions, or that the fast paced, short lived, ever-changing computer industry will turn its back on XML any time soon as its foundation, SGML has existed for 17 years baring many offspring that are widely used as we all know, and has finally reached such wide industry acceptance of standards (well at least better than many others or the beloved 2 party CSV agreements) that I cannot see how it can disappear anytime soon. In fact I really do believe it will play the major role towards achieving the 3rd generation WWW, the beloved hype term of semantic web.

Essentially I think that the benefits of XML are direct and immediate, but the harm caused by its inherent inferiority, as Mr. Pascal believes, is long-term and abstract. Just know that if the computer industry follows past behavior, direct and immediate wins every time.

Now slaughter me for being such an overnight "expert" wannabe

[Dr Livingston]

And I don't really go by other folks views etc myself either.

I like XML - a lot - and w/out XML and it's related technology (i.e. XSL) the whole idea of data exchange over the Internet would never have been so bloody easy to do as you can today.

Also Web Services would never have been either - let's see anyone (Fabian Pascal for example ?) come up with a better method of data integration and exchange and fine - I'll use that instead.

Doubtful though 8)

As for the weakness of XML sure there are a few but the advantages far, far outway the few disadvantages.

[MarcusJT]

I don't have the time to read Pascal's full article right now, and I shall do so when I can, but for the moment, it would appear from your comments and selected quote that his comparison (and thus his conclusion) is rather unfair, since 99% of the time XML is NOT used for storing a single table of data (which is what he appears to be talking about) - it is used for storing structured and/or relational data, containing the equivalent of many tables of data.

Storing the same data in CSV format would require multiple output files, and would be far more complex to parse, process, and recreate the original hierarchical data. In contrast, XML data (after a relatively simple parsing stage) is easily manipulated, thanks to DOM & SAX parsers and XSLT.

It would be incredibly difficult to replicate the functionality of XSLT with a multiple-file, CSV-based data source.

I feel that I'm rambling now (probably because i only had 3hrs sleep last night), so I'll stop, but I think you should know what I mean.... right?