[
Lists Home |
Date Index |
Thread Index
]
for me, but if this
is Paul's refutation of the "browser is dead" thread,
it is
a good statement of the UIVM idea, long on politics, but it is a
blog.
The
University of Waterloo did some similar work but I've long since lost
the library
reference for that. The idea
dawned on me while we were doing
the MID work for the Navy. Our sponsor at
Carderock, Eric Jorgensen, referred
to it
as a notional player. Eric is an often uncredited but far-sighted
guy.
That
was the IETM world where the requirements were elaborated
in the
contexts of a US Tri-service requirement for a common IETM presentation
system. Separation of presentation logic and properties
and database
properties was an assumed part of the IETM strategy before the web.
CALS
was the original Thor's hammer of SGML and the nascent
hypermedia lunatic fringe. The problem was that there
were lots
of
IETM browsers, but each one was owned by a company, had it's
own
formats, and so on. Proprietary, as Mike says, and worse, usually
tied
to one or the other services. Since the IETMDB was already
a fait
accompli, what was needed was the means to deliver the
presentation in a neutral language. We designed MID for that,
but
we
were too late and OBE.
The
UIVM concept worked for the MID, it works for web browsers, and so
on.
It did
depend on a language (the candidate then was MID II) that made the
GUI
features dominant: ease and expense of authoring is a
factor.
Still,
it isn't a hard idea to grasp. As I've said before, anyone who ever
opened a
Windows 3.1 resources file got the idea quickly. Where
it fell apart
in
SGML was exactly where one would suspect: the need or application
of
SUBDOCs because otherwise, associating the database to the
presentation
wasn't
easy to do using standard means. This was before XML and before XML
namespaces.
One
of the folks that looked at MID and worked with it a bit was Jean Paoli
then
at GRIF. Yuri Rubinsky came to tell me later that no one would
use MID because
HTML
had to succeed at any price. As he said, "for the first time
in
its
history, SoftQuad is showing a profit". Sorry folks, but a lot
of
web
pioneers had to do that to keep "contributing". It isn't that only
profits matter, but that profits matter.
So
nothing new under the sun, but historical precedents show that
different groups without cross-pollination arrived at essentially the
same
idea
and found it both attractive and implementable. That, as I recall, means
it
passes TimBL's principle of independent invention filter.
The
critical problem, market wise, is the legacy. Otherwise, does
XHTML
have
the right stuff? The question is simply, as you put it, are there enough
advantages to make the pain of adoption worthwhile? I don't
know. Browsers
are
freebies, so a lot of that pain is some other vendor's to suffer. My only
point
is that that are options that would enable them to say "you can do
that
with this other model" (eg, XDocs, smart clients, what have you) and
avoid
the pain or the costs. What you should be looking for is something
that
can be done with XHTML 2.0 that can't be done other ways for the
same
or less cost.
len
In a message dated 20/11/2002 16:43:15 GMT
Standard Time, clbullar@ingr.com writes:
Andrew:
1. Does XHTML 2.0 have a future?
Yes. For those who believe in and
want to pursue development of
the Universal Interface Virtual Machine (UIVM)
as Paul calls it, a
native language for that machine is needed.
Is
http://www.blogstream.com/pauls/1034787029
the fullest
development of that idea?
Although it seems to have been less than
obvious to a few on this list I am actually trying to explore what I see as
a serious issue.
| 