A Look At The Advantages and Drawbacks of XML

M

mike myers

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

BGB

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

Manuel Collado

El 22/01/2013 11:30, Richard Tobin escribió:
You'd think a commercial company would be able to afford higher
quality spam.

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

Joe Kesselman

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

Absolutely agreed.
I expect that the mentioned commercial product doesn't suffers from
these mistakes.

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,
http://www.love-song-productions.com/people/keshlam/index.html

{} ASCII Ribbon Campaign | "may'ron DaroQbe'chugh vaj bIrIQbej" --
/\ Stamp out HTML mail! | "Put down the squeezebox & nobody gets hurt."
 
P

Peter Flynn

XML means Extensible Mark-up Language

[snip]

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
 
R

Richard Tobin

Peter Flynn said:
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.

That would be the charitable explanation. But you'd think they would
have noticed by now.

Take a look at
http://www.articlerich.com/Article/A-Evaluation-Of-The-Advantages-and-Drawbacks-of-XML/2526065

Then look at
http://www.articlerich.com/profile/Alex-Hopkirk/122587
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
articles.

-- Richard
 
D

Denis McMahon

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

The registrant of liquid-technologies.com seems to be "liquid
technologies ltd"

Registrars.
Registrant:
Liquid Technologies Ltd
68 St Winifreds Av West
Harrogate, HG2 8LS
GB

Domain name: LIQUID-TECHNOLOGIES.COM

Administrative Contact:
Sprott, Simon (e-mail address removed)
68 St Winifreds Av West
Harrogate, HG2 8LS
GB
07950 291545
Technical Contact:
Sprott, Simon (e-mail address removed)
68 St Winifreds Av West
Harrogate, HG2 8LS
GB
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:
LIQUID TECHNOLOGIES LTD
STATION HOUSE STATION ROAD
ARTHINGTON
OTLEY
WEST YORKSHIRE
UNITED KINGDOM
LS21 1NN
Company No. 04105577
 
R

Richard Tobin

The registrant of liquid-technologies.com seems to be "liquid
technologies ltd"

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
 
R

Richard Tobin

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

-- Richard
 
R

Richard Tobin

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

.... and they have replied saying they have "raised this as an issue
with our SEO company, so hopefully this will not be repeated".

-- Richard
 
P

Peter Flynn

XML means Extensible Mark-up Language

[snip]

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

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.

That would be the charitable explanation. But you'd think they would
have noticed by now.

Not really. Marketing people are notoriously blind to technological error.
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.

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
 
R

Richard Tobin

Peter Flynn said:
but perhaps they will have removed the shill
their "SEO company" hired.

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
 

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. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,982
Messages
2,570,189
Members
46,734
Latest member
manin

Latest Threads

Top