Why use XML?

[Brian]

I have been reading a book on XML and am beginning to see the potential of
XML to abstract the content out of web pages similar to how CSS abstracts
out the design portion. However, I am failing to see how this can improve
my web development projects right now. Accessing XML files directly, formatted
by CSS, you are going to run into older browser incompatibilities. I mostly
use PHP/MySQL to build my dynamic sites and I can't seem to see how XML can
be incorporated to make a significant improvement. I've read that "using
XML in conjunction with a relational database allows you to harness the power
of both" but I just don't see the advantage of using them together. I am
very interested in learning more about XML, but why should I continue if
I can't find an advantage over my proven/reliable relational database? Does
anyone have any advice, examples, or ideas as to how to take advantage of
both?

[Russell Jones]

The advantages are not always apparent at first, and they depend on what
your site does. For example, if your site consists primarily of static HTML
pages, the main advantage you can reap from XML is in making your pages
XHTML-compliant. That way, you can use an XML parser to find and alter
specific elements in your site programmatically (and generically) rather
than writing custom search-and-replace code. In contrast, if you build
"template" pages that you fill with data on request from a relational
database, you may find that you can offload a considerable portion of the
processing requirements to the clients in many cases--letting the clients
handle filtering and sorting for example, or you can use XML documents to
cache data and reduce the load on your database server.

Using XML, far from *causing* problems with browser incompatibilies, helps
you *solve* browser incompatibilities generically, using XSLT stylesheets to
deliver the same information to different clients in different ways. You can
perform these transforms on the server, caching the results when possible,
so you don't need to rely on your clients' CSS capabilities to use XML
effectively.

Using XML with relational databases lets you use the database to store and
deliver data values, while simultaneously giving you a searchable sortable,
storable format to make that data available to applications which don't have
or to which you don't want to give direct access to the database. XML Web
services let you expose server-based functionality to client-side
applications. For example, you can often use Web services to update pages
with server-based data *without* redrawing the entire page.

If you have specific questions about how XML might help in your particular
situation, let us know exactly what it is that you're doing, and someone
here will help.



"Brian" <bwurster@verizon.net> wrote in message
news:3df3e563$1@tnews.web.devx.com...
>
> I have been reading a book on XML and am beginning to see the potential of
> XML to abstract the content out of web pages similar to how CSS abstracts
> out the design portion. However, I am failing to see how this can improve
> my web development projects right now. Accessing XML files directly,
formatted
> by CSS, you are going to run into older browser incompatibilities. I
mostly
> use PHP/MySQL to build my dynamic sites and I can't seem to see how XML
can
> be incorporated to make a significant improvement. I've read that "using
> XML in conjunction with a relational database allows you to harness the
power
> of both" but I just don't see the advantage of using them together. I am
> very interested in learning more about XML, but why should I continue if
> I can't find an advantage over my proven/reliable relational database?
Does
> anyone have any advice, examples, or ideas as to how to take advantage of
> both?

[Ricky Vega]

Also, because it is a standard, all types of projects are bieng developed
that can take your XML file and easily convert it into another format. In
the Microsoft world, you can exchange data between office applications as
Office XP has XML Schemas to describe Office XP documents.
XML DTDs are a way to "type check" data exchanged from other sources rather
than hand coding all your data validation code. This will also cause this
validation to occur on the client side without the user waiting for the validation
check to return from the server (and incurring the server overhead that is
inherent along with this process).
There are open source projects that allow XML data to be transformed into
useful document types such as RTF and PDF (see http://xml.apache.org/fop/).

Because XML is a standard, you can create an Excel 2002 document in OS/390
COBOL if you wanted to as the file is in the Schema expected by Excel 2002.
Hope this helps..
'ta..

"Russell Jones" <arj1@nospam.northstate.net> wrote:
>The advantages are not always apparent at first, and they depend on what
>your site does. For example, if your site consists primarily of static HTML
>pages, the main advantage you can reap from XML is in making your pages
>XHTML-compliant. That way, you can use an XML parser to find and alter
>specific elements in your site programmatically (and generically) rather
>than writing custom search-and-replace code. In contrast, if you build
>"template" pages that you fill with data on request from a relational
>database, you may find that you can offload a considerable portion of the
>processing requirements to the clients in many cases--letting the clients
>handle filtering and sorting for example, or you can use XML documents to
>cache data and reduce the load on your database server.
>
>Using XML, far from *causing* problems with browser incompatibilies, helps
>you *solve* browser incompatibilities generically, using XSLT stylesheets
to
>deliver the same information to different clients in different ways. You
can
>perform these transforms on the server, caching the results when possible,
>so you don't need to rely on your clients' CSS capabilities to use XML
>effectively.
>
>Using XML with relational databases lets you use the database to store and
>deliver data values, while simultaneously giving you a searchable sortable,
>storable format to make that data available to applications which don't
have
>or to which you don't want to give direct access to the database. XML Web
>services let you expose server-based functionality to client-side
>applications. For example, you can often use Web services to update pages
>with server-based data *without* redrawing the entire page.
>
>If you have specific questions about how XML might help in your particular
>situation, let us know exactly what it is that you're doing, and someone
>here will help.
>
>
>
>"Brian" <bwurster@verizon.net> wrote in message
>news:3df3e563$1@tnews.web.devx.com...
>>
>> I have been reading a book on XML and am beginning to see the potential
of
>> XML to abstract the content out of web pages similar to how CSS abstracts
>> out the design portion. However, I am failing to see how this can improve
>> my web development projects right now. Accessing XML files directly,
>formatted
>> by CSS, you are going to run into older browser incompatibilities. I
>mostly
>> use PHP/MySQL to build my dynamic sites and I can't seem to see how XML
>can
>> be incorporated to make a significant improvement. I've read that "using
>> XML in conjunction with a relational database allows you to harness the
>power
>> of both" but I just don't see the advantage of using them together. I
am
>> very interested in learning more about XML, but why should I continue
if
>> I can't find an advantage over my proven/reliable relational database?
>Does
>> anyone have any advice, examples, or ideas as to how to take advantage
of
>> both?
>
>

[Dennis D.]

"Ricky Vega" <leperOBGYN@darkware.net> wrote:
What XML can do is process transactions across other servers that use a common
vocabulary, regardless of the platform, the application, or the user client
given that each has ability to use the required XML components. XML is at
the heart of web services. The primary advantage of XML is that it is much
easier to read and write than JAVA. It seems to be the HTML that everyone
wanted to happen in the first place. The emphasis is on separating the content
from the formatting, yet retaining characteristics of a database and spreadsheet
language, such as Visual Basic for Applications.

I think it appeals to people because the vocabularies allow some retention
of the discrete properties of a discipline, meaning that logistics entities
won't need to interface with physics entities. Each vocabulary will accommodate
that special interest, and not others.

The web services concept is that if you have a book selling business, your
computers will share the same vocabulary with the printers, the paper manufactures,
and other peripheral businesses that are your vendors or customers. At that
point, your combined computers can 'talk' to each other, while performing
much of the work using automation. Once an order for a book is presented,
the automation goes to work. The order becomes a transaction which flows
through a chain of processes including being handed off to the manufacturing
unit, then finally through a distribution channel which delivers it to the
customer, all without the personal intervention of humans. The financials,
inventory, and related administrative and support functions listen and act
as a response to the transaction flowing through the system. The front of
the system looks like this: guy walks into store, picks up book, swipes card,
owner smiles, guy leaves with book. The backend of the system is automated
with all the related tasks getting updated by the transaction or order.

As I said, the big difference between what we are using now is how easy it
is to read and write the language. Easier is cheaper. Unfortunately, I think
it will be putting a bunch of admin people out of work, and XML programmers
will not be able to command as much money as JAVA programmers.

The current discussion surrounding XML and web services centers around security.
Other than that they are a done deal. IBM and several other large corps have
been pushing web services for awhile, and the concept is catching on.

I'm not going to jump through the hoop to re-write my website for XML and
web services. However, I am re-writing it for search engines, and may incorporate
XML where it might benefit the site.

There is a lot of free and usable data being pushed through XML pipes. If
you can connect to it, then it might be a valuable asset for your site.

dd
webmaster,
http://www.dennisys.com/

[Jim]

Keep in mind there are many applications for XML (EDI, XBRL, etc), not just
web development. Nevertheless, web development is an extremely important
implementation of XML. With that in mind, consider the elements of a web
site. Each page within a web site usually has something in common with all
of the other pages on that site. These common attributes add continuity to
a site. Some examples of common items are links, logos, layout, etc. One
potential application for XML (my favorite application as a web developer)
is to use XML/XSLT to extract those common site specific elements into one
file, then, using a build process, distribute those elements into each file
on the site (similar to the distributive property in math A(B+C) = A*B+A*C).

Let's say I'm building a web site like http://www.canyon-view.com. Each page
on that site has something in common with every other page on that site.
Each page has the same copyright notice, site map, and layout. By taking
the copyright statement, site map, and layout out of each document and placing
it into an XSL template or a series of XML files, the site author only has
to maintain each of those items in one place.

Continuing with the http://www.canyon-view.com example, let's say that I
add a new section to this web site titled "Beginning Java." Without a single
location to maintain links to sections within that site (site-map.xml), I
would have to add a link to this new section on every page of that site.
Instead, I've chosen to maintain the site map within an XSL template and
use that XSL template to process each document on that site.

For more information regarding this topic, see http://www.xml.com/pub/a/2000/07/26/xslt/xsltstyle.html
and http://xml.apache.org/forrest for examples of this approach.

As far as viewing XML (excluding XHTML) directly using CSS with a brower,
you are correct, the browser "playing field" is not ready for this yet, and
I, therefore, don't recommend this approach. Whether or not the browser "playing
field" will ever fully support this depends on how people perceive browsers.
Is a browser a browser in the sense that it should display any type of XML
document using the rules specified in a CSS stylesheet? Or is a browser really
an HTML browser capable of displaying HTML natively and other forms of XML
(SVG, Excel XML, etc) only through the use of plugins?

XML was not designed to be a final, presentable document for either screen
or print. Instead, XML (as far as it relates to documents, not data) is meant
to be used as a technology to separate the presentation logic from the actual
document. Other technologies, such as XSLT, were designed to convert XML
documents and XML data into presentable documents in any format (PDF, SVG,
Postscript, Word, HTML, etc). This allows the document writer to focus on
the content of the document and the graphics artist to focus on the layout
of the document.

I don't recommend browsing XML directly from any browser as each browser
that supports browsing XML uses a different XSL processor. Even within the
same browser version it is not possible to tell which XSL processor will
be used to process your page (with MSIE 5-6, the browser could be using either
MSXML 1 through MSXML 4). Instead of viewing XML directly in a browser, I
recommend using a windows script (if you are using windows) or a shell script
(if you are using Linux/Unix) to process your XML files through an XSL processor
to create resultant XHTML files, then viewing those XHTML files with your
browser. If you are creating dynamic pages, then I recommend using server
side transformations (Perl, ASP, PHP, etc) to transform XML into XHTML, then
returning the resultant XHTML to the requesting web browser. For static pages,
you can use http://xml.apache.org/forrest to build an entire web site from
XML documents and database content ensuring a common theme (skin) throughout
the web site.

If you are just considering including database content in a web page that
shares no common attributes with any other pages on that site, then, no,
XML may not be the solution. On the other hand, if you have pages that contain
both database content and common attributes (logo, etc), then consider using
a piping/chaining technique to pipe the results of one transformation (converting
the database data to a document) through another transformation (transforming
the document into a web page with attributes common to all pages on your
site) to create the resultant web document.

As far as "using XML in conjunction with a relational database... to harness
the power of both..." The familiar method for transforming a database into
HTML usually involves using a series of loops to intermix HTML tags with
the contents of database records, then writing the results to a web browser.
I generally use a method to first transform the contents of a database to
XML, then use XSLT to transform that XML into HTML. This separates my programs
into program logic, presentation logic, and data. The presentation logic
is stored in an XSL file, the program logic in an executable file, and the
data in a database. I can then modify the presentation or data without affecting
the executable program logic. Many databases support the creation of XML
natively allowing you to request query results as XML. I noticed that you
use MySQL. Unfortunately, MySQL doesn't support XML natively yet. However,
there are several projects in development for using MySQL with XML. Take
a look at http://sourceforge.net/projects/phpsqlxml for an XML API for use
with MySQL and PHP.

Another potential reason to convert database data to XML is to generate dynamic
images such as charts and graphs as SVG documents.

XML and XSLT can even be used to generate javascript. For example http://www.homchick.com
contains a tax form due date calendar. This calendar contains a div that
is displayed and hidden based on the position of your mouse (yes, a "flyout"
menu). The contents of this "flyout" menu come from an XML file containing
due dates and forms. Using an XSL template, I convert the contents of that
XML file into javascript that looks something like:

var dueDate1_2Menu = new FlyoutMenu();

dueDate1_2Menu.className = "clsCalendarMenu";

dueDate1_2Menu.add(new FlyoutMenuHTML("Forms <a href=\"./glossary/forms.html#f730\"
class=\"deadLink\">Form 730</a>, <a href=\"./glossary/forms.html#f2290\"
class=\"deadLink\">Form 2290</a>, and <a href=\"./glossary/forms.html#fW5\"
class=\"deadLink\">Form W-5</a> are due Fri, January 3, 2003"));

For more information regarding the use of XML on the internet, I strongly
encourage you to look at http://xml.apache.org and http://www.jenitennison.com.
I have found Jeni's insite and apache's tools to be invaluable in web development.

"Brian" <bwurster@verizon.net> wrote:
>
>I have been reading a book on XML and am beginning to see the potential
of
>XML to abstract the content out of web pages similar to how CSS abstracts
>out the design portion. However, I am failing to see how this can improve
>my web development projects right now. Accessing XML files directly, formatted
>by CSS, you are going to run into older browser incompatibilities. I mostly
>use PHP/MySQL to build my dynamic sites and I can't seem to see how XML
can
>be incorporated to make a significant improvement. I've read that "using
>XML in conjunction with a relational database allows you to harness the
power
>of both" but I just don't see the advantage of using them together. I am
>very interested in learning more about XML, but why should I continue if
>I can't find an advantage over my proven/reliable relational database? Does
>anyone have any advice, examples, or ideas as to how to take advantage of
>both?

[Alex Oss]

"Dennis D." <xmo@dennisys.com> wrote:
>As I said, the big difference between what we are using now is how easy
it
>is to read and write the language. Easier is cheaper. Unfortunately, I think
>it will be putting a bunch of admin people out of work, and XML programmers
>will not be able to command as much money as JAVA programmers.

May I ask what an "XML programmer" is? I thought XML was a data storage
format, not a programming language.

Thanks!