Lists Home |
Date Index |
- From: Deke Smith <email@example.com>
- To: <firstname.lastname@example.org>
- Date: Mon, 1 Feb 99 15:20:52 -0600
As someone who uses Frontier with XML I will try to make a brief outline
of my experiences (I can get a little verbose sometimes).
Frontier is a good example of how some people use XML in a PRODUCTION
ENVIRONMENT. All the users of the current version use XML whether they
know it or not. As part of a subscription to Frontier, the user is
provided constant updates for bug fixes and new features. Those updates
are provided via HTTP using XML. The documentation can be downloaded and
referenced from within the program and that, too, is updated the same
way. Both of these uses of XML are invisible to the end user...
I think many people who are currently using Frontier as a processor for
XML would agree with this:
Tyler Baker, email@example.com said on 2/1/99 11:56 AM:
>There seems to be a major misconception here I think in terms of what
>needs to do for businesses. The issue for XML I think should be
>just raw speed. What use is the XML/XSL architecture if it costs mucho
>in development dollars for fly-by-night consultants, overpriced databases,
>application servers. Maybe some giant bank has money to burn, but the
>web-shop if they are even profitable is running their business on very thin
>margins. Raw performance of using XML is not what should be the focus here,
>simplicity should be the focus.
In a production environment where expediency is important as well as
flexibility and reuseability, *TODAY* XSL is not the answer. If I am not
mistaken, XSL is still in working draft. I have based work I have done on
a working draft before and had to redo it later to be reuseable. There is
a need, and tools like the Xmltr Suite have filled the vacuum in the
I have tried to see how much XML Frontier can munch on and used the
religion xml files as a stress test. Last time I tried (three months ago)
Frontier could not parse that quantity of text at one time. It coughed a
hair ball about a quarter of a way through it.
As far as being a repository for terabytes of information...that is an
interesting question and one that sounds intriquing enough to try.
Parsing huge files may be a problem as I mentioned before. Although most
of Frontier's information is stored in the main database of the program
called the 'root', 'guest' databases can be created as needed.
Unfortunately I don't have a terabyte disk drive nor do I think I can
scrounge up a terabyte worth of information on my own to try.
I search for XML data once it is inside of Frontier by creating indices.
Right now, indices are pretty much a roll your own proposition.
I have a database of approximately 1,000 contacts from around the world
in an XML file. That way, it can be edited by volunteers who have no
computer experience on Mac, Windows, Unix, BeOS, etc. I can bring this
data into Frontier and create a "Yahoo-style" directory from the
information with about a hundred pages. I also can replicate the
directory in Spanish and German using XML-based dictionaries to translate
geographic names and interface elements. After creating my scripts, it
takes me about thirty minutes to bring the revised listing into Frontier
and get it started. A couple of hours later it is done and the Website
online has been updated via FTP.
Tallent Communications Group, Brentwood TN
"Cats are smarter than dogs. You can't get eight cats to pull a sled
- Jeff Valdez
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)