Page 2 - XML Basics (part 2)

If you are using PHP to parse xml documents, especially xhtml documents, then chances are you are running into trouble using standard html entities like ' ' that you have grown accustomed to. All you have to do, is find the numbered equivalent to the named entity, and the parser won't cough on you. So instead of 'é' you use 'é'

Links

- w3schools: http://www.w3schools.com/html/html_entitiesref.asp

- w3c.org: http://www.w3.org/TR/REC-html40/sgml/entities.html

(1)Why Isn't SGML Enough
XML doesn't do anything SGML couldn't always do But...XML avoids several of SGML's barriers to acceptance and use
Specification is small (about 30 pages)
No optional features makes implementation cost easier to judge Makes it clear how light-weight clients can be built
Avoids the stigma of the "SGML" name
"SGML is 'big iron', tired, outdated"
"XML is hip, happening, now"
(2)Why Isn't HTML Enough?
HTML fine for presenting tex or structuring Web pages HTML has no well-defined or definable structural rules HTML cannot convey rich structures and semantics HTML not acceptable as an authoring or archival form for many kinds of data HTML is too tightly bound to browser implementations
3. Conclusion: We Need XML
Need a light-weight, user-friendly form of SGML
.Need everything we like SGML for:
.Arbitrary document types Rich structuring and semantics
.Well-defined and controlled syntax
.Clearer separation of content from style and behavior
.Richer data model to enable richer addressing
.XML provides a powerful marketing vehicle for selling the benefits of SGML to a new audience
.Gets a whole new group of people thinking about how to take advantage of structured markup

(1)Why Isn't SGML Enough
XML doesn't do anything SGML couldn't always do But...XML avoids several of SGML's barriers to acceptance and use
Specification is small (about 30 pages)
No optional features makes implementation cost easier to judge Makes it clear how light-weight clients can be built
Avoids the stigma of the "SGML" name
"SGML is 'big iron', tired, outdated"
"XML is hip, happening, now"
(2)Why Isn't HTML Enough?
HTML fine for presenting tex or structuring Web pages HTML has no well-defined or definable structural rules HTML cannot convey rich structures and semantics HTML not acceptable as an authoring or archival form for many kinds of data HTML is too tightly bound to browser implementations
3. Conclusion: We Need XML
Need a light-weight, user-friendly form of SGML
.Need everything we like SGML for:
.Arbitrary document types Rich structuring and semantics
.Well-defined and controlled syntax
.Clearer separation of content from style and behavior
.Richer data model to enable richer addressing
.XML provides a powerful marketing vehicle for selling the benefits of SGML to a new audience
.Gets a whole new group of people thinking about how to take advantage of structured markup

This message, not XML. (The discussion is now old and probably stale.) Others in this thread have mentioned such things as post-relational databases, using XML files as databases, etc.
<p>
XML will not replace your database. They should re-read part one of this series. XML is a data-interchange file format, primarily. Your database should be built to third normal form, correct in all respects. It can handle non-hierarchical data (you probably have quite a few many-to-many relationships, lookup tables, links between items, views, etc.) but when it comes time to transmit a subset of your data elsewhere, you should probably do so in an orderly fashion. XML is a way of, in a text file, representing the output from, say, a report or a simple query. Whether it's representing a few objects, or a large chunk of your data, XML can represent in a readable, standard way your finished output to other systems. Straight XML can be re-input into other systems that might convert the data back into INSERT's into a database, or they might simply be browser clients such as cell phones, computers, or automated telephone systems. If you plan your output from the point of view of data, you'll get XML. It says nothing about presentation, just about content. It doesn't contrain your lookup tables, it doesn't do nifty calculations, it does nothing that you wouldn't expect out of good reporting software (remember, this is output from something else.) But this XML data can now be transformed (XSLT) into formats readable by other systems. To support a new client, write a new transformation, and your existing XML data is fine for the job. Note that regardless, clients will have to understand the data. It's one thing to mark tags as being of type 'person' but for that to mean something to other software is quite a leap. Clients, to make sense of XML, will always have to know in advance what they're looking for. But at least they can expect data in a single format, XML. (as opposed to CSV, fixed-column, or some form of binary.)
<p>
Yes, it can be used for storage. No, I don't recommend it. No, it won't simply immediately make your company and another company work together seamlessly. But it might make the programmers on the other side not hate you so much. And managers think it's hip. Personally, I still like .ini files!

XML Basics \(part 2\)

Now that you know the basics, this article explains how to use XML's more advanced constructs to author complex XML documents. Entities, namespaces, CDATA blocks, processing instructions - they're all in here, together with aliens, idiots, secret agents and buried treasure.

Please discuss this article in this thread. You can read the article here .