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/
[EMAIL PROTECTED]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
