Extensible Markup Language
Extensible Markup Language(aka XML)
From http://www.w3.org/XML/ :
XML applications discussed here:
Other:
So, the language is pretty much just SGML - enough so that existing SGML parsers read it. SGML parsers have been around for donkey's years, and no one uses them except typographers, so what's the big deal? Standards? Sure, standards are good, and adhering to them is good, and a standard way to describe data formats is good - which is what SGML is. Why should I care about XML when I practically never needed to worry about SGML before? Is the whole thing just browser-marketing crud - is XML this year's "push"? -- PeterMerel
One of the reasons for the success (if you regard it as such) of Unix was that most of its tools could be linked by piping ASCII strings around, and lots of the tools used name/value pairs in a standard format. Nothing exotic there, but enough people stuck to the conventions to make the whole greater than the parts. ExtensibleMarkupLanguage is certainly nothing new, but it could give us a new generation pipe format so that we can get some of these systems can talk to each other. Like HTML, the appeal is that in that it's so stupid. Anyway, I would have thought that providing EDI standards is one of the key problems for the next few years...
Okay, I like that explanation a lot. But what XmlPattern?s are there? Say I was going to build an XmlWiki? - what could that do that this here bundle of wires and sealing wax can't do? -- PeterMerel
For example, I can imagine using Xml as an underlying storage format that's easy to parse, to manage meta-data, and for sending across a wire for replication.
With XsltLanguage you have a declarative way of transforming one kind of XML into another. This saves you from writing a parser.
You could also use a carefully-crafted 'wiki XML' DTD along with some XSLT to move pages between wikis with different WikiEngines.
But what is really happening with it? Microsoft and Netscape have both claimed that they will support it, but how far off will that be? Moreover, who is working with it today? It may be the next big thing, or it may fall flat. The fact that herald call has preceded wide spread use makes me wonder. It seems these days that the "next big thing" is whatever snuck up on you and became pervasive while you weren't looking. -- MichaelFeathers
The ExtensibleMarkupLanguage is considered to be the new SilverBullet when in fact there is nothing magic or silver about it. The magic about XML is that it allows you to be creative and think of your own data-centric solution. XML is a misnomer in that it does not define a markup language, it defines a set of loose rules that you use to build your solution. The nice aspect about XML is that it gets people back to thinking about solutions instead of OverusingTools?.
"We absolutely do not see XML as a client-side technology, since that would involved pushing our clients' data dictionary and schemas over the wire." - I think this is missing the point. The XML you push over the wire is not the same stuff you store internally. Instead you water it down via XSL and send low-fidelity version of your XML language, just as HTML is lower-fidelity. XML is not one language. It is a set of tools for doing language transformations.
Incidentally, I'm finding XML jolly useful on a very small scale for writing UnitTests. My input data is a static XML string; I present it to a parser which turns it into an in-memory data structure. I send some probing messages. Then I reconvert it back into XML and compare the result against another static string to verify the new structure is what it ought to be. XML is providing me a way to talk about the state of my application. Since it also gives me an important import/export format, and a default file format, it's pretty economical - especially if the tools are standard. -- DaveHarris
Interesting. At the Nov. 2000 SF Bay XP meeting, I was with one of 3 XP projects using XML-scripted FunctionalTests (no common link between them). I suspect XmlScriptedTests? (and XML strings as proxies for comparing objects) are becoming popular. -- JeffreyMiller
So, the language is pretty much just SGML - enough so that existing SGML parsers read it. SGML parsers have been around for donkey's years, and no one uses them except typographers, so what's the big deal? ... Why should I care about XML when I practically never needed to worry about SGML before? -- PeterMerel
In my mind, a key difference between SGML and XML is one of complexity. SGML has a whole bunch of rules that allow you to omit terminating elements, relying on context to infer the missing pieces. These rules are very useful for people writing SGML by hand, but are very complicated to code - writing an SGML parser is a very involved process. XML on the other hand, was explicitly designed to be easy to implement - I believe the original goal was that a Graduate Computer Science student should be able to implement a complete parser in under a week. Having XML so easy to implement is (IHMO) a major reason for its popularity. -- BevanArps.
The remaining bits I'm not comfortable touch -- What I did so far was RefactorByExtractingToPage. A gentle touch on the remaining comments would be appreciated -- StevenNewton
I worry about the sheer size and growth of XML related standards, mainly because YouArentGonnaNeedIt. I'm more hopeful for the future now that I've seen these efforts:
...enough people stuck to the conventions above
And applications are getting stuck in the networks
ZapThink? has a report in late 2004 to explore solutions for the XmlPerformance issue. There is a link to their views on binary compression as a way out at http://www.zapthink.com/report.html?id=ZAPFLASH-11162004
See XmlAndSoapAreGoodForWhat, XmlExamplesOfGoodUsage, and AllOnePiece for different perspectives
EditText of this page
(last edited April 10, 2012)
or FindPage with title or text search