Re: XML vrs SGML tools [was Re: Capitalizing on HTML (was ...)]
Paul Prescod wrote:
> >We needn't worry about XML-only editors or
> >dedicated XML browsers because there won't be any.
Not true. Some use generalized SGML editors. Some will create
very process specific editors. IOW, give us an easy parse
and an object handler to support that, and we will build
Visual Basic-level applications to support very specific
Document types. SGML/XML is the syntax.
> I would word this a little differently: "We can't _depend_ on XML-only
> editors or dedicated XML browsers because there MAY NOT be any." (especially
> in the short term)
> >2. The browsers need to be able to work without accessing a DTD.
True, but not necessarily always. Some will work that way. Some won't.
I don't wish to spawn a new thread or divert the working
group from its scheduled tasks. But we can get overfocused
quickly on HTML and the existing Web and the poverty
of Joe Homepage.
The Web is not the Internet.
HTML is here to stay, but as James Clark
and others note, it is already well-supported; furthermore,
the vendors choose to make it a battleground for market
share and that is not an attractive place to compete. As
I noted elsewhere, when the lock is secure, one looks
for different houses to burgle. In this case, I think a different
generation of applications (editors and browsers) will
be spawned by this effort. Otherwise, it would not
be a profitable investment of our time, IMO.
My reason for participating in this working group is not
to fix the existing generation of tools, applications, or
data (i come to bury caesar, not to praise him). If that happens,
good. But I think a different class of opportunity exists here.
Here is a quote from PC Magazine (091096):
"... a LAN-based client/server application can take
advantage of the power of the client PC to partition
processing and data storage tasks. In contrast,
a Web database is reminiscent of an old-time mainframe
application, with the browser acting as an ultrathin
client, analogous to a dumb terminal. While LAN
developers are free to exploit the all the client
machine's processing power and all the features
of its windowing system, Web developers have
to work within the limitations of the HTML
standard, unless they wan to make assumptions
about user's local configurations.... The server
makes no provision for storing vital information
about the application and the user within the
application. This approach is fine for delivering
hypertext documents but creates huge headaches
for anyone trying to design a tight multipage database
application. To overcome this problem, a Web
application needs eithter to maintain session
information or to pass state information back and
forth to the user via embedded information in the
HTML.... Another difficult problem is the upredictable
load a Web application may encounter... A web database
that can make frugal use of database connections
is a real plus."
To make the client do more work, the application
data needs more smarts, and in many ways, this means
a more domain-specific DTD. To make clients do
more work, the domain must be narrower, not a
one size fits all. Right now, we are transmitting layout
information over and over. That isn't smart.
I want to use SGML On The Web to
create smart data. This is a doctype-to-doctype
protocol, if I can use the term loosely.
I don't particularly care that anyone anywhere
on any machine can process it. I care that two
systems can use the Doctype
or catalog information in addition to the MIME
type to determine that they already have or can
fetch the required software to process a message where
that message is a specific type of document
used in a specific step in a specific process,
e.g, I send RFQ; return Quote or RFI.
This is a transaction at the document level,
where that transaction may result in
configured local events upon receipt.
In one app, EDI with SGML. Please, yes I know
other groups and standards lay claim to this
area of application. I don't care.
There is a whole category or niche of applications
that can be deployed that will exist between the
dumb terminal and the database-to-HTML
server applications. This is the unburgled
neighborhood overlooked to this time
in order to make the easy kill with thin clients.
This is a very easy thing to sell to those
who have MONEY to buy applications.
This is how they do business and it is
what they understand. Client-server,
they don't understand. Hypermedia,
they don't understand. Document to
document business processes, this they
understand. It is not that I wish to
see HTML and Joe Homepage suffer,
I do not wish to make everyone else
suffer in their cause.
Make SGML easier to write applications
for, and that is possible. It opens up the
real market for SGML. We will not profit
from continuing to exploit HTML. That
house is already under lock and key,
and its foundations are crumbling.