The Gordian Data
There's a famous story about the eastward blitzkrieg of Alexander the Great
through Asia Minor. On a narrow isthmus at the town of Gordia, on the only road
to the east, there was a wagon left by the legendary Gordius, which had stood there time out of mind. The
crossbar of the yoke was tied with cornel bark rather than rope, as they usually were, to the bar attached
to the cart. Untypically, this knot was of mind-numbing complexity and size.
Legend had it that Asia Minor would never fall to any conqueror who could not
unravel this knot. As was the tradition, Alexander was led to this puzzle, which
had stumped all who went before him, none of whom were successful in taking
Asia Minor.
Impetuous Al took one look at the massive snarl, shrugged, and cleaved it with
a blow of his sword. It seems that with oxbows as with life, the direct, unorthodox approach is often the best.
We need to cut through a lot of mystery that surrounds data management, especially
as it lives on the web. Actually, the RSS standard is pointing the way to the
future of most data on the web, and RSS may be the means to cut through the Gordian
Data problem.
The standard for large data-driven web sites is to connect the web (html) server
to a separate data server, which supplies the data to be displayed in the user's
browser and which stores the data provided by the user. Special code in the
web page triggers a Common Gateway Interface (CGI) which talks to the data server
and gets and puts the required information. Every time the user hits such a
web page, there are two events: fetch the web page and fetch the data to be
displayed on the web page. When the web form is submitted, there are another
two events, tell the page you're done and move the data to the data server.
Data for the Rest of Us
Interestingly, a web page is a database. It contains information
which, when requested by an authorized user, is served to the user. It's not
elegant and it's useless for large data sets, but it still has all the characteristics
of a data base.
Until the world wide web, there never had been a public data record like a
web page. The web's breakthrough was to totally expose some set of useful data to anyone, without restriction.
who had the web address. This was, I submit, a bigger deal than even we web
junkies acknowledge.
My mantra is that proprietary data is the root of tyranny.
If information has no use, it's not considered data. But if it has been elevated
to data status, it's needed by somebody and protected by someone else. Whether
it's a driver's license record, Visa account or the Most Wanted List, when you
need to have the data you are subject to the demands of the party controlling
the data. It is what gives governments power over their subjects and police
the power to make your life a mess. It's why it's bad form for a government
to detain its citizens without putting them on a public data list so others
can see what's going on among their peers.
The Data Problem
When you build a data base, you need a trained data guy who will use specialized
software to design the data forms and connect them to the data base, which
is usually a table with a header row of the data types and another row for each
record (person or property or airline flight). Sounds good, but the problem
is that the tools are quite specialized and each data base is custom-built for
its owner. That means it's hard for another designer to step in and modify the
data base, since it's a little like a computer program.
This means the data base owner is dependent on the designer, which he doesn't
want to be, and the designer is an indentured servant to the owner, which he
doesn't want either.
So we've got an ungainly data source that's available to everyone and buildable
by almost everyone's niece - the web page. And we've got a cumbersome, expensive
specialized tool understandable by only a few and fully understood only by the
designer. Where's the middle ground?
The data problem is really two problems: interface and data integrity. Data
for the Rest of Us needs a lot of people who know how to design a useful
interface with low cost tools. That would be web design. Since all data is finding
its way onto the web, we're making the web page our default interface standard.
That leaves the back end data problem. There are thousands of people who will
design you a web page, but hardly any of them can even spell "data".
Most owners of data bases want to get information from their customers, not
just digitize their brochure. The best that small outfits can usually get from
their designer is the ubiquitous web-to-email tool which dumps the info they
want into their inbox. If you want something useful, you'll spend more than
a small outfit can, or use one of the one-size-fits-all solutions, which locks
you in to a single vendor.
Find Your RSS with Both Hands
The RSS solution is elegant. It codes your info as categorized text using XML
tags like <title>Jaws</title>, <director>Spielburg</director>,
etc. And it puts it right on the web where anyone can see it. Since it's just
text, it can be written by many tools, and because it's systematically tagged,
machines can read the data and slice and dice it, just like a "real"
data base.
The problem is that "the Rest of Us" and our web designers still
need an expert to customize the RSS feed for our purpose. RSS is real progress
that stops just a little short for anyone but bloggers and news syndicators.
The Gordian breakthrough is to store data right on the user's web site using
XML as the data store. Suddenly any web designer is able to design the data
input form, if they have a tool to parse their preferences into PHP code.
XWriter.php
This fall, you'll be able to download an open source script that lets a web
designer add data tools to their web sites. The only skill they'll need are
these:
- Know where the data display folder is on your web site
- Know where the data input folder is on your web site
- List your data types, which XWriter converts to a parseable string
- Drag the XWriter-created data display strings or input strings to your WYSIWYG
editor
- Click on a graphic representation of the 6 form types and 2-4 options for
each input
- Click Process
That's it. XWriter adds the needed PHP code to your web page, puts the page
where directed and opens it for testing. XWriter was developed for creating
and modifying Xpertweb forms but its uses are so broad it's been enhanced for
use on any PHP-equipped site.
The XWriter tool is being developed by Hurai
Rody, who has done a great job working on a strange concept. We're indebted
to him.
8:24:31 PM 
|
