>Just a quick note on how we see HTML+ going in the immediate future,
>this is taken from the HTML+ workshop at WWW'94. Proper minutes where
>the difference between my opinions and those of others can be
>distinguished will be posted in due course :-)
Were there many people from the SGML world there?
>1) First priority is to build a coherent spec defining what we do now
>to give to the commercial companies.
Will it be a validated SGML DTD? HTML was not validated until long
*after* it was released...
>2) HTML+ should start to emmerge soon. This will offer much better
>support for tables and figures. Maths will follow.
That's good to hear. If you are doing tables, I would recommend using
one of the more popular SGML table systems (CALS, AAP, etc).
>On this point there will be some negotiating and bargaining between
>the spec editors over resolving legacy issues between HTML+ and DTDs
>designed for special needs.
More on this later.
>BTW this process takes time and also means that the process of
>standardisation cannot be the usual internet model of the first
>person to produce code. This is not an electronic democracy but a
>meritocracy.
In this case, I think it is good. A bad stabdard now could cause
huge problems later. A good standard now will guarantee the
continuance of the WWW, and information system built upon it.
>That said the issue of style and style sheets is very important. The
>main priority though is supporting the forms of expression such as
>tables and maths which are currently not supported before doing pretty
>fonts etc.
In addition to the fine point you have made about different
publishers wanting different typographical styles, I would add that
SGML should only be used to define the structure of a document, not
the formatting (which is where stylesheets come in). This allows
things like structured searches top be performed very efficiently,
and has other benefits as well (Machine independence for example.
Could you *really* render HTML on a voice synthesis machine? How
would it know when a new chapter in a book began? H? elements are
used primarily for font effects in HTML...)
>Keeping it simple while still allowing powerful expression is the
>objective. It is not our aim to produce a spec that is simple through
>not being functional. We want to be both functional and simple.
A nobel idea. I am sure that you will do a fine job on HTML+.
However, I don't feel that any DTD will ever satisfy the needs of
everyone. I feel that HTTP needs to be extended to allow for
negotiation on DTD's, stylesheets, pay-per-use, encryption, and other
things in order for commercial publishers to be really successful. For
example: Say Encyclopedia Britannica was online. How could they charge
people for using it? What would stop someone in a country with lax
copyright laws from copying everything, and then putting it onto the
net somewhere? What if they had the Encyclopedia Britannica marked up
using an DTD they designed (down converting to HTML is possible, but
can produce weird results)?
I would like to see HTML+ as the common thread, where is all else
fails, every server, and every client should understand it, but I
would also like it to be possible to have clients and servers who are
aware of more than one DTD, and more than one stylesheet. As machines
become faster, and as the public domain SGML parsing engines become
better, and easier to use, there will be very little reason to
restrict client to only one DTD, and it seems short-sighted to do so.
This is all IMHO of course.
Gavin "*Not* speaking for EBT" Nicol