A Look At The Advantages and Drawbacks of XML

Discussion in 'XML' started by mike myers, Jan 22, 2013.

  1. mike myers

    mike myers Guest

    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 meantit 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 datavia 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 500pages 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 usinglimited 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 bodytag.

    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 isthe 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 ofa 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.
    mike myers, Jan 22, 2013
    1. Advertisements

  2. mike myers

    BGB Guest

    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).

    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...
    BGB, Jan 22, 2013
    1. Advertisements

  3. You'd think a commercial company would be able to afford higher
    quality spam.

    -- Richard
    Richard Tobin, Jan 22, 2013
  4. El 22/01/2013 11:30, Richard Tobin escribió:
    Not only higher quality spam, but also less disinformative one.

    The OP fails to realize that SGML and XML are markup *notations*, while
    HTML is a markup *language*. So he compares carrots with rabbits.

    I expect that the mentioned commercial product doesn't suffers from
    these mistakes.
    Manuel Collado, Jan 22, 2013
  5. Absolutely agreed.
    Probably true; I haven't tried it.

    For other descriptions of the tradeoffs of XML, and of various uses of
    it and approaches to it, I recommend the many tutorials and articles on
    http://developerworks.ibm.com/xml. Yes, that's an IBM-sponsored site, so
    there may be some editorial bias. However, the DeveloperWorks editors
    think of themselves as an independent web-zine, and while IBMers are
    encouraged to contribute articles which express IBM's point of view
    there have also been many contributions from outside the company, some
    of which directly conflict with IBM's own positions. And IBM is more
    concerned about making XML a useful set of tools, which tends to mean
    any overall bias is toward standards and good practices rather than
    toward any one product or solution.

    (And a personal disclaimer: I spent some time as IBM's rep on the W3C's
    DOM Working Group, and contributed to IBM's XML parser and
    XPath/XSLT/XQuery engines, so I may be more biased than DeveloperWorks is.)

    Joe Kesselman,

    {} ASCII Ribbon Campaign | "may'ron DaroQbe'chugh vaj bIrIQbej" --
    /\ Stamp out HTML mail! | "Put down the squeezebox & nobody gets hurt."
    Joe Kesselman, Jan 22, 2013
  6. mike myers

    Peter Flynn Guest


    I have emailed the sales contact addresses from the website of Liquid
    Technologies bringing this to their attention.

    I am assuming that this individual was hired by a marketing agency who
    failed to carry out any checks on the credentials of the individual
    before allowing them to damage the credibility of the company.

    Peter Flynn, Jan 22, 2013
  7. That would be the charitable explanation. But you'd think they would
    have noticed by now.

    Take a look at

    Then look at
    which has similar articles going back nearly two years.

    There are also dozens of similar blog articles under other names such
    as "Tony Hardacre" and "Miccheal[sic] Dupre", all with links to the
    same company.

    Incidentally, some of the errors in the article seem to be due to
    using an automated tool to change words so as to disguise duplicate

    -- Richard
    Richard Tobin, Jan 22, 2013
  8. The registrant of liquid-technologies.com seems to be "liquid
    technologies ltd"

    Liquid Technologies Ltd
    68 St Winifreds Av West
    Harrogate, HG2 8LS


    Administrative Contact:
    Sprott, Simon
    68 St Winifreds Av West
    Harrogate, HG2 8LS
    07950 291545
    Technical Contact:
    Sprott, Simon
    68 St Winifreds Av West
    Harrogate, HG2 8LS
    07950 291545

    I suspect that the failure of these advertisements to include the company
    registered name and number and registered address may be a breach of
    legislation relating to UK registered companies.

    Name & Registered Office:
    LS21 1NN
    Company No. 04105577
    Denis McMahon, Jan 23, 2013
  9. One of the other companies advertised by the same spammer is called
    "AutoVIP". If you Google for 'autovip "liquid technologies"' you will
    find that the common factor is someone called "Tahire" at a company
    called "SearchLab". They claim to use "use only ethical, white hat
    methods to get you onto the first page of Google". I wonder if
    Google would take the same view?

    -- Richard
    Richard Tobin, Jan 23, 2013
  10. I've mailed Liquid Technologies in the hope that they are unaware of
    the methods being used to advertise them. I'll let you know how they

    -- Richard
    Richard Tobin, Jan 23, 2013
  11. .... and they have replied saying they have "raised this as an issue
    with our SEO company, so hopefully this will not be repeated".

    -- Richard
    Richard Tobin, Jan 24, 2013
  12. mike myers

    Guy Guest

    Guy, Jan 31, 2013
  13. mike myers

    Peter Flynn Guest

    I too had a reply from them, saying exactly the same as Richard
    received. At least they took the time to reply: at a guess it will be
    the last we hear from them, but perhaps they will have removed the shill
    their "SEO company" hired.

    Not really. Marketing people are notoriously blind to technological error.
    He's obviously just a dickhead trying to make himself a fake name as a
    writer. Exactly the kind of person who can con marketing people into
    paying them, alas...

    Peter Flynn, Feb 1, 2013
  14. But that's what SEOs do. However much they deny it, search engine
    optimisation *means* generating bogus links - that is, ones whose
    purpose is just to boost the page rank. This SEO employee was just
    incompetent at hiding the fact that he was doing it.

    -- Richard
    Richard Tobin, Feb 2, 2013
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.