On 1/22/2013 2:28 AM, mike myers wrote:
> XML means Extensible Mark-up Language and it's a mark-up language created for moving as well as exhibiting data or data all over the internet, in a reliable and as planned fashion no matter the systems or browsers being used. Consequently XML is utterly platform independent and is available freely.
>
> XML was really developed to precede SGML and HTML, each of which are mark-up languages although had their very own limitations and also constraints. For example, SGML was basically incredibly complex and expensive, this meant it was very difficult to use for the web, specially because it was not being sustained by any of the commercial browsers.
>
> On the subject of HTML, in spite of being at no cost and widely supported, it had a number of main flaws making it inappropriate for use carrying data via the internet.
>
> Thus XML was developed out of SGML through a group of IT experts from IBM and Sun, who used the best parts of SGML and cut down the unused, complex and unwieldy parts. The final result would be a simple, extensible and open specification which was only 26 pages long, in comparison with more than 500 pages that the SGML specification came with.
>
> Consequently that’s the basic history v XML, let’s right now take a quick look at just what XML is along with what it looks like.
>
> In relation to code syntax, XML is similar to HTML, i.e. you have an opening tag that looks like <xml>, and a closing tag that looks like </xml>
>
> Other than the opening and closing tags, most of an xml file is actually pairs of opening and closing tags with data (collectively, the tags and data are termed XML Elements).
>
> Having presented a concise history on XML and going for a quick look at just what it looks like, lets right now dive right into the pros and cons, opening of course with the positives.
>
> The first and most apparent benefit is that in contrast to HTML, XML tags do not have semantic meaning; this means that you’re not bound in to using limited tags, for instance, in HTML you have to use the body tag to position your body elements or the head tag to place the head elements.
>
> With XML you really construct your own tags to suit your needs and you could point whatever you like in between your tags, there isn't any restrictions within the rules e.g. with HTML only body elements can go within the body tag.
>
> Another gain is the fact that in addition to tags, you may also create and compose your own rules, and these rules, as opposed to HTML, don't constrained to formatting rules, XML enables you to define all forms of tags with all kinds of rules, for instance tags representing business rules or tags representing data description or data relationships.
>
> Despite the many benefits, there is also one major disadvantage that has prevented XML staying more substantially used than it is at present, which is the absence of suitable processing applications.
>
> With HTML for example, you can actually use virtually any browser to read any HTML document which isn't the situation with XML, since there are at present no XML internet browsers available. For that reason XML documents ought to be changed into HTML before you distribute them or even to make use of a middleware program to convert it on the fly.
>
> Having said that, parsing tools and algorithms are continuously evolving and also new advancements are making it simpler than previously to work with XML, and so many people are discovering the benefits to moving their data to XML. Finally, commercial XML tools such as http://www.liquid-technologies.com/xml-editor.aspx will be able to tremendously improve your capability work with and edit XML based files and documents.
>
> A far more thorough account of XML can be obtained from this http://www.liquid-technologies.com/xml.aspx or you can certainly check out the W3C website for more information.
>
pros of XML:
fairly common;
fairly flexible (can represent a wide variety of types of data).
cons of XML:
very verbose;
lacks a native data model well suited to high-performance processing (*1).
*1:
SAX is is not a data model.
DOM is generally lackluster from the POV of a data model (typically
awkward to work with, and doesn't get very good performance).
many people use XML for data-binding type uses, but this does not give
XML a data model, merely uses it to express another.
it is possible to create a DOM-like model and address some of the
performance and usability issues, but then it is no longer really DOM,
and lacks the same sort of de-facto support.
for example, I had used some rather specialized representations of XML
trees in some of my compiler front-ends. but, this involved such absurd
craziness as having attributes that could be... numbers... among other
things (attributes were internally either an integer, a double, or a
string, vs in DOM where everything is strings, as well the concept of a
separate "Document" entity was largely discarded).
a contrast would be either S-Expressions or JSON, which although
sometimes expressed in forms stripped of their inherent data
representations (their RFC forms), it doesn't take much to look where
they came from (Lisp and JavaScript), and have a good idea what a
sensible data-model should look like and how it should behave (and
promptly discard the contents of the respective RFCs).
likewise, if well implemented, code written against one of these data
models may well run circles around code designed to work with DOM from a
performance POV.
also, mysteriously, they tend to mesh with programming languages as well.
for example, it is possible to write some code with fairly solid
performance built around things like list-processing (say, for 3D
rendering tasks or as the core of a languages' type-system).
doing similar with DOM may not seem like such a good idea (so people
will instead map the data to objects within the language, ignoring the
possible use case of having the DOM nodes *be* the sole data structures).
a drawback though (for lists of JS-like objects) tends to come if the
form of generality and flexibility:
the semantics of the data may not be strictly independent of the
restrictions imposed by an implementation, or some people may be heavily
off-put by something not all about static-types and class hierarchies
(and as a result isn't quite as "language agnostic" as a format for
"structuring and shoving around a bunch of strings").
they may come from the tradition where homogeneous arrays are the *only*
"acceptable" option, and the idea of heterogeneous lists may seem rather
alien, regardless of whether or not the language they are using can
actually do so adequately.
flexibility may more come in the form that it may be fairly easy to use
the data-model in such a way that one ends up boxed into a corner, with
little escape apart from potentially breaking some pre-existing code
(typically by writing code that expects lists or objects to be laid out
in a narrowly defined and particular way), with the cost that making
code more general may result in reduced efficiency or higher verbosity.
in contrast, the natural way of doing things in XML is fairly verbose,
and "the general way" tends to also more often align with "the easy
way", so there is generally less temptation for people to fall into
cases of "concise, but not really flexible".
or, at least, these are a few opinions...
Similar Threads
