Re: Re: XML, what is that supposed to do?

I thought I might weigh into this debate in a small way. My background is a little different. I have spent the last five years playing with SGML ( Standard Generalised Markup Language ) which is the ancestor of XML - basically, XML was invented by elements of the SGML community to create a "lighter" form of SGML that could be used in client side apps and didn't require a CRAY to be able to do things quickly. The primary benefit of XML is that you have more control over the markup of your data. This has several aspects 1) You can markup a piece of data to describe what it *actually is* rather just marking it up how you would like it displayed in one particular media - it puts some intelligence in the data and allows you to mark up some of the context that us humans are generally able to infer. This also "future proofs" your data against the "display" formats changing. 2) You can use a DTD (Document Type Definition) to create the compliance part of what I like to call a "data contract" - two or more parties can agree on a data format that suits them. The contract is "if you give me data in this format I can process" it. XML allows you to

    (a) have a standard way to write these "contracts"
    (b) provided standard tools to check whether the "contract
        conditions" have been met

3) If you are creating more than one kind of output, you need to be able

    to store the original content in such a way that it is easy to
    create the different kinds of output.

What this means is that one of the most currently useful places to use XML a *storage* format. If all you are doing with you data is delivering it in a bland way to Web browsers, then you may as well just use HTML. If you have to deliver two kinds of HTML ( eg: frames/ no frames ) and set of PDF files, then XML is an excellent way to store your data - there are heaps of tools out there than can easily do the transformations. Re Tools: the other posters have done quite a good job of summarising some of the tools and standards. I will only add a couple of things. 1) Calling "DOM" the big brother of "SAX" is not really correct - they are more like cousins. They each have their place and used for different things. If you need to be able to arbitrarily rearrange the elements of an XML "tree" into weird and interesting shapes then go with the "DOM" but don't expect to process anything larger than about 1MB. When speed and size are an issue, you need to use a serial/event driven processor such as Omnimark or a SAX tool. 2) What I understand about XSLT is

    a) It is a tree based processor so you have all the limitation
        of the "DOM"
    b) It is an absolute pig to write code in by hand

but other than that it's fine ..... Regs Brian White ------------------------- Brian White Step Two Designs Pty Ltd - SGML, XML & HTML Consultancy http://www.steptwo.com.au/ bwhite@steptwo.com.au