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.

Len Bullard
Lockheed Martin

Received on Friday, 20 September 1996 10:45:59 UTC