XML

Assignment 1

Group members

1. Sufian Bin Sarin 2009967979

There are three guys at IBM which is Charles Goldfarb, along with Ed Mosher and Ray Lorie who
invented GML in 1970’s.The GML is a way of marking up technical documents with structural tags.
Goldfarb said, he invented the term “mark-up language” in order to make better use of the initials. Then
it became the Standard Generalized Markup Language (SGML) and was adopted by the ISO in 1986.
There are some confusing about SGML because it is not fully markup language but rather a specification
for defining markup languages. The most popular application of SGML is HTML (Hypertext Markup
Language) which an application that defines a specific set of tags suitable for web pages.

However, SGML is pretty darn complex, especially for the everyday uses of the web. Not only that, but
SGML is pretty expensive. Adding SGML capability to a word processor could double or triple the price.
Finally, the commercial browsers made it pretty clear that they did not intend to ever support SGML.

On the other hand, the HTML was free, simple and widely supported. The HTML was originally designed
at CERN around 1990 to provide a very simple version of SGML which could be used by many people.
The usage of HTML spread very fast after that.

Then, although the HTML are widely use , unfortunately it has serious defects and then things began to
go horribly wrong. The original idea was to separate content from presentation. For example,
the <em> tag in a web page means “emphasize”. It was left up to the user agent how to render that, say
as bold text, or in a different color, or with a different tone of voice in a speech reader. This type of thing
does not please page designers, who want to nail down the exact appearance of a page. Therefore
HTML got extended with things like <font> tags which went right against the initial concept. Another
problem area was that fierce competition between Netscape and Microsoft led to fragmentation of the
standard, which remains a huge problem for web developers. Web pages began to be used for things
that went wildly beyond the original concept, including multimedia, animation, online applications,
ecommerce and more. Browsers also tried to be tolerant of hastily written web pages that committed
crimes like using an opening tag without a corresponding closing tag. Tolerance is normally
commendable, but the resulting lack of discipline became a barrier to programmatic interpretation of
web content, or the use of HTML for structured data.

In a nutshell, HTML is too limited and terminally polluted, while SGML itself is reckoned to be too
complex for mortals to implement.
So in 1996, discussions began which focused on how to define a markup language with the power and
extensibility of SGML but with the simplicity of HTML. The World Wide Web Consortium (W3C) decided
to sponsor a group eleven member of SGML gurus including Jon Bosak from Sun, Tim Bray, James Clark
and a hundred and fifty member interest group.

The working group had the following goals:

-Internet usability
- SGML compatibility
- General purpose stability
- Formality
- Conciseness
- Legibility
- Ease of authoring
- Minimization of optional features

Michael Sperberg-McQueen compiled design decisions and the theory behind them on December 4,
1997. They came up with XML, Extensible Markup Language. James Clark was the Technical Lead of the
working group, and his contributions include the name "XML" and the empty element syntax. Initially
the specification co-editors were Tim Brag and Michael Sperberg-McQueen. They were later joined by
Jean Paoli as the third co-editor. The XML was designed using emails and weekly teleconferences, and
after twenty weeks (July to November 1996) of hard work and major decisions, the first working draft
was released.
Advantage and Disadvantage of XML

Advantages of XML

There are many advantages of XML. The first advantage is that because we are writing our own markup
language, we are not restricted to a limited set of tags defined by proprietary vendors.

Rather than waiting for standards bodies to adopt tag set enhancements (a process which can take quite
some time), or for browser companies to adopt each other's standards (yeah right!), with XML, you can
create your own set of tags at your own pace.

Of course, not only are you free to develop at your own pace, but you are free to develop tools that
meet your needs exactly.

By defining your own tags, you create the markup language in terms of your specific problem set! Rather
than relying on a generic set of tags which suits everyone's needs adequately, XML allows every
person/organization to build their own tag library which suits their needs perfectly.

That is, though the majority of web designers do not need tags to format musical notation, medical
formula, or architectural specifications, musicians, doctors and architects might.

XML allows each specific industry to develop its own tag sets to meet its unique needs without forcing
everyone's browser to incorporate the functionality of zillions of tag sets, and without forcing the
developers to settle for a generic tag set that is too generic to be useful.

However cool the idea of escaping the limitations of a basic tag set (like HTML) sounds, it isn't even close
to the best thing about XML?

The real power of XML comes from the fact that with XML, not only can you define your own set of tags,
but the rules specified by those tags need not be limited to formatting rules. XML allows you to define all
sorts of tags with all sorts of rules, such as tags representing business rules or tags representing data
description or data relationships.
Consider again the case of the contact list in SCLML. Using standard HTML, a developer might use
something like the following:

<UL>

<LI>Gunther Birznieks

<UL>

<LI>Client ID: 001

<LI>Company: Bob's Fish Store

<LI>Email: gunther@bobsfishstore.com

<LI>Phone: 662-9999

<LI>Street Address: 1234 4th St.

<LI>City: New York

<LI>State: New York

<LI>Zip: 10024

</UL>

<LI>Susan Czigany

<UL>

<LI>Client ID: 002

<LI>Company: Netscape

<LI>Email: susan@eudora.org

<LI>Phone: 555-1234

<LI>Street Address: 9876 Hazen Blvd.

<LI>City: San Jose

<LI>State: California

<LI>Zip: 90034
</UL>

</UL>

While this may be an acceptable way to store and display your data, it is hardly the most efficient or
powerful. As you are probably aware, there are many potential problems associated with marking up
your data using HTML. Three particularly serious problems come to mind:

1. The GUI is embedded in the data. What happens if you decide that you like a table-based
presentation better than a list-based presentation? In order to change to a table-based
presentation, you must recode all your HTML! This could mean editing many of pages.
2. Searching for information in the data is tough. How would you get a quick list of only the clients
in California? Certainly, some type of script would be necessary. But how would that script
work? It would probably have to search through the file word for word looking for the string
"California". And even if it found matches, it would have no way of knowing that California
might have a relationship to "New York" - that they are both states. Forget about the
relationships between pieces of data which are crucial to power searching.
3. The data is tied to the logic and language of HTML. What happens if you want to present your
data in a Java applet? Well, unfortunately, your Java applet would have to parse through the
HTML document stripping out tags and reformat the data. Non-HTML processing applications
should not be burdened with extraneous work.

With XML, these problems and similar problems are solved. In XML, the same page would look like the
following:

<CLIENT>

<NAME>Gunther Birznieks</NAME>

<ID>001</ID>

<COMPANY>Bob's Fish Store</COMPANY>

<EMAIL>gunther@bobsfishstore.com</EMAIL>

<PHONE>662-9999</PHONE>
<STREET>1234 4th St.</STREET>

<CITY>New York</CITY>

<STATE>New York</STATE>

<ZIP>Zip: 10024</ZIP>

</CLIENT>

<CLIENT>

<NAME>Susan Czigany</NAME>

<ID>002</ID>

<COMPANY>Netscape</COMPANY>

<EMAIL>susan@eudora.org</EMAIL>

<PHONE>555-1234</PHONE>

<STREET>9876 Hazen Blvd.</STREET>

<CITY>San Jose</CITY>

<STATE>California</STATE>

<ZIP>90034</ZIP>

</CLIENT>

As you can see, custom tags are used to bring meaning to the data being displayed. When stored this
way, data becomes extremely portable because it carries with it its description rather than its display.
Display is "extracted" from the data and as we will see later, incorporated into a "style sheet".

Let's consider some of the benefits.

1. With XML, the GUI is extracted. Thus, changes to display do not require futzing with the data.
Instead, a separate style sheet will specify a table display or a list display.
 2. Searching the data is easy and efficient. Search engines can simply parse the description-bearing
tags rather than muddling in the data. Tags provide the search engines with the intelligence they
lack.
3. Complex relationships like trees and inheritance can be communicated.
4. The code is much more legible to a person coming into the environment with no prior
knowledge. In the above example, it is obvious that <ID>002</ID> represents an ID whereas
<LI>002 might not. XML is self-describing.

Disadvantages of XML

However, awesome XML is, there are some drawbacks which have hindered it from gaining widespread
use since its inception. Let's look at the biggest drawback: The lack of adequate processing applications.

For one, XML requires a processing application. That is, the nice thing about HTML was that you knew
that if you wrote an HTML document, anyone, anywhere in the world, could read your document using
Netscape. Well, with XML documents, that is not yet the case. There are no XML browsers on the
market yet (although the latest version of IE does a pretty good job of incorporating XSL and XML
documents provided HTML is the output).

Thus, XML documents must either be converted into HTML before distribution or converting it to HTML
on-the-fly by middleware. Barring translation, developers must code their own processing applications.

The most common tactic used now is to write parsing routines in DHTML or Java, or Server-Side perl to
parse through an XML document, apply the formatting rules specified by the style sheet, and "convert"
it all to HTML.

"While it's true that browser support is limited, IE 5 and Netscape 5 are expected to fully support XML.
Also, W3C's Amaya browser supports it today, as does the JUMBO browser that was created for the
Chemical Markup Language.

XML isn't about display -- it's about structure. This has implications that make the browser question
secondary. So the whole issue of what is to be displayed and by what means is intentionally left to other
applications. You can target the same XML (with different XSL) for different devices (standard web
browser, palm pilot, printer, etc.). You should not get the impression that XML is useless until browsers
support it. This is definitely not true -- we are using it at NASA in ways where no browser plays any role."
- Ken Sall

However, this takes some magic and the amount of work necessary even to print "hello world" are
sometimes enough to dissuade developers from adopting the technology.

Nevertheless, parsing algorithms and tools continue to improve over time as more and more people see
the long-term benefits of migrating their data to XML. The backend part of XML will continue to become
simpler and simpler. Already Internet Explorer and Netscape provide a decent amount of built in XML
parsing tools.