What is so great about XML?

[Lauren Wilson]

OK, I have been drowning in all kinds of articles about XML lately.
The ONE thing I have not yet seen is a general discussion article
about the alleged benefits of XML, especially as it affects Access
developers.

Does anyone have a link to such an article -- one that STARTS with a
general description of why XML is suppose to be better than whatever?

Thanks in advance.

[Trevor Best]

Lauren Wilson wrote:

OK, I have been drowning in all kinds of articles about XML lately.
The ONE thing I have not yet seen is a general discussion article
about the alleged benefits of XML, especially as it affects Access
developers.

Does anyone have a link to such an article -- one that STARTS with a
general description of why XML is suppose to be better than whatever?

Thanks in advance.

Lemme guess, you're writing an application and everyone keeps asking
"does it do XML?", the same people who just accidently deleted "the
innernet" from their desktop.

--
[Oo=w=oO]

[Steve Jorgensen]

On Thu, 12 May 2005 02:11:16 -0500, Lauren Wilson <no****@private.com> wrote:

OK, I have been drowning in all kinds of articles about XML lately.
The ONE thing I have not yet seen is a general discussion article
about the alleged benefits of XML, especially as it affects Access
developers.

Does anyone have a link to such an article -- one that STARTS with a
general description of why XML is suppose to be better than whatever?

Thanks in advance.

I have had a chance to do a lot with XML lately, and I have a few things to
say.

First, a lot of folks who haven't played with XML, but just read about it will
tell you it's nothing new. Those people are both right and wrong.

Yeah, in one sense, XML is just a tagged file format, and yes, CSV can do a
lot of what we would use XML for just fine, but that ignores certain key
points.

1. It's a standard that a vast majority have been able to agree to share.

2. Regardless of the fact it can be difficult for a human to read, it is
nevertheless possible, and XML data really is more self-describing than CSV.

3. Standard XML parsers do a large part of your validation for you based on
the DTDs or XML Schemas for your document formats.

4. Standard XML parsers are able to apply XSLT transformations to XML data to
translate between formats. For instance, a client of 2 products from 2
vendors is likely to be able to write XSLT to translate one vendor's XML
format to the other. Since at least one of the applications probably bothered
witing the 15 lines of code or so to allow specifying an XSL Transform to
apply during load/save, you probably don't need to add an extra external
processing step.

5. Name spaces and the nested nature of XML allow you to borrow parts of other
standard schema definitions when designing your own and get increased data
portability in the bargain.

6. A single DTD or schema can define elements for a whole suite of document
types that share many common elements between them. Changes to any element
type definition are managed in one place.

7. Increased use of XML document formats allows for reduced coupling between
applications. For instance, I can use the MSXML library to generate XML from
a VB program that Excel can open directly, and do it without using Excel
automation - Excel doesn't even have to be installed on the machine that
generates the document.

Now, as far as Access goes...
From what I can see, the only really useful XML feature in Access so far is
the ability to use the MSXML library in the VBA project, which has more to to
with VB than Access per se. So far, it's been easier to figure that out than
how to use the explicit XML mapping features of Access (or Execl or SQL Server
for that matter) in any useful way. I'm pretty confident that will improve
eventually.

[billmiami2]

I would add to Steve's answer that there is another place where you
might use XML in your access application--consuming or calling web
services using SOAP calls. XML is the format used for communicating
with web services, which can be described simply as function calls
across the internet.

I know that some Microsoft products (such as MS Project Server) provide
an API that allows you to interact with the product via SOAP. In order
to upload data, retrieve data or make a configuration change, you will
need to create XML requests and receive XML responses. You can do with
with MS Access using the SOAP and XML libraries available to you.

Of course, you might also design an Access application that combines
local data stored on an access database with data retrieved from an
external source via web service calls to a third party's web service.
For example, you might store a company's financial information in an
Access database but provide the ability for the user to quickly look at
up to the minute stock market activity for the company and its
competitors. You would do this by making an XML request to a third
party web service that provides stock price information. I think that
Yahoo was providing a free web service for this. There are web
services that provide all kinds of data out there any many of them are
free.

Bill E.
Hollywood, FL

[David W. Fenton]

Steve Jorgensen <no****@nospam.nospam> wrote in
news:02********************************@4ax.com:

Now, as far as Access goes...
From what I can see, the only really useful XML feature in Access
so far is the ability to use the MSXML library in the VBA project,
which has more to to with VB than Access per se. So far, it's
been easier to figure that out than how to use the explicit XML
mapping features of Access (or Execl or SQL Server for that
matter) in any useful way. I'm pretty confident that will improve
eventually.

But you only need *that* if you've got a need for XML exchange with
somebody outside your Access applicaiton.

In other words, the answer to the subject's question is NOT MUCH.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[billmiami2]

Interestingly, only hours after we responded to Lauren, someone else
posted with a need to do the very thing we were describing--right down
to the stock price example. See

"Access VBA and Web Services (XML)"

Bill E.

[Larry Linson]

"Steve Jorgensen" wrote

1. It's a standard that a vast majority
have been able to agree to share.
And, I think it may be even harder to get people in information technology
to agree than it is to get agreement from a roomful of lawyers.
2. Regardless of the fact it can be
difficult for a human to read, it is
nevertheless possible, and XML
data really is more self-describing
than CSV.

Comma-Separated Variable format text files aren't self-describing at all, so
that's not a big leap. XML files, particularly with schemas and XSLT, are
self-describing. XML is just a current-generation "markup language" -- those
have been used since mainframe days, mostly for text files and display
control, but XML extends the functionality. But, they are, indeed, just text
files with agreed conventions for interpreting them.

The rest of these are "detail" information.

But, the big, big reason to be "excited" about XML, if you are, is that it
is a standard that has been agreed. There are, however, disagreements in
various groups defining "protocols" for data exchange in various industries,
a necessary next step for making XML data useful!

Larry Linson
Microsoft Access MVP

[David Schofield]

On Thu, 12 May 2005 02:11:16 -0500, Lauren Wilson <no****@private.com>
wrote:

OK, I have been drowning in all kinds of articles about XML lately.
The ONE thing I have not yet seen is a general discussion article
about the alleged benefits of XML, especially as it affects Access
developers.

Does anyone have a link to such an article -- one that STARTS with a
general description of why XML is suppose to be better than whatever?

Thanks in advance.

Hi
Here is an article which at least starts with what you asked for. It
is a fairly jaundiced view!
Coping with XML:
http://xmlsucks.org/but_you_have_to_...-with-xml.html

On the other hand there are those who think XML makes other database
technology obsolete. For example
Why XML?
http://www.softwareag.com/xml/about/xml_why.htm
This sort of approach often takes the view that the relational model
is old fashioned and the new way is hierachical, which should make
anyone whose father used Codasyl databases smile a bit.

However there IS a mismatch between the relational model and current
object-oriented approaches, which in practice results in modelling the
real world twice in each application.

Here is a reference to using XML as an in-memory database which looks
quite sensible. It exploits the fact that conventional databases are
connected very loosely to the application and so have a huge
connection overhead in server-client operation:
Creating an In-Memory Database Using XML and XPath -- Part 1
http://www.15seconds.com/Issue/010409.htm

David