Re: Back to basics
> [...] the goal of the W3C SGML activity is to enable Web browsers to
> receive and process generic SGML in the way that they are now
> able to receive and process HTML.
Agreed.... however, if that were the only issue,
SoftQuad Panorama would satisfiy it, no? We can all go home :-)
Well, OK, there are still issues --
* Panorama is only shipping on Windows (Unix and Mac are in early beta)
* Panorama deals with documents, not fragments. I don't want to subvert the
discussion towards SGML OPEN fragments, but only to note that Panorama
can't deal with 100 MByte documents
* Panorama works with Netscape and MSIE and Mosaic, but other browser writers
need to work with us & write a DLL (for Windows) to communiate
* Panorama can't (as far as I can tell) work on Unix as a helper-app unless
you edit your SGML to add a processing instruction giving the document's
URL. This is because under Unix you can't ask Netscape for the URL of
the document you've been asked to fetch -- you just get handed a tmp file.
We might be able to use the Netscape plugin API to deal with this. The
CCI spec (asking the user to specify an IP port number) is unworkable.
However, Panorama under Windows with documents no larger than 4 MBytes works
pretty much like a standard web browser. I therefore assert that the goal
stated above is already satisfied.
That doesn't mean I don't think XML is not a bad idea. I fully support the
idea of a regular, simplified version of SGML that can be parsed easily.
Let's make SGML uniquitous, as Michael SMcQ put it in his fabulous closing
speech at SGML 95 last December (is that online anywhere??).
So perhaps I am unclear on how to interpret the Goals.
> One factor that we know has prevented the wide deployment of generic SGML
> browsers is the difficulty of implementing the complete 8879 specification.
Well, it has prevented devlopment of multiple browsers. And even Panorama
implements only the required features of SGML. No OMITTAG, no SHORTTAG
(actually some SHORTTAG features are there, but I don't think net enabling
tags are supported, for example) no DATATAG or SHORTREF (I've hardly ever
even seen those used, but maybe that's self-selection), no LINK, no CONCUR,
no RANK (I think), no SUBDOC... don't know about CURRENT.
You can always run James' spam on the server, right out of the can, and
remove the minimisation features that Panorama doesn't understand. In fact,
use of OMITTAG is a frequent source of error, so it should probably be added.
I have listed lots of things Panorama can't do, not because I don't like it
(it's a fabulous piece of software) but because I want to show that you can
go a long way without supporting those features. They are not needed.
Perhaps LINK and SUBDOC are hardest to do without; I have recently seen a
way (I think) to do subdoc, as long as it is used as an entity-valued
attribute and not just <CHAPTER>&otherdoc;<TITLE>... which is somewhat harder.
LINK can be done in an odd sort of way with HyTime. Using external markup
and connecting it to a document frame with HyTime is very powerful.
So for deploying SGML on the web, I think we are there today, and the right
question may be `Is this where we want to be? Why are we not satisfied?'.
I don't want to start a flame war about this. Clearly Panorama does _not_
satisfy the goal in everyone's minds, or this list wouldn't exist.
Or is the stated goal merely a political front for a Higher Goal? (better
reply privately on that one!)