Re: <draft-ietf-iiir-html-01.txt, .ps> to be deleted.
Dave_Raggett <dsr@hplb.hpl.hp.com>
Errors-To: listmaster@www0.cern.ch
Date: Wed, 16 Feb 1994 16:11:30 --100
Message-id: <9402161505.AA17851@manuel.hpl.hp.com>
Errors-To: listmaster@www0.cern.ch
Reply-To: dsr@hplb.hpl.hp.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: <draft-ietf-iiir-html-01.txt, .ps> to be deleted.
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 3530
Dave,
> In the future, I expect several other factors to become important. These
> are:
> 1) the willingness of large information providers to subsidize the
> interconnections
> 2) the affordable creation and maintenance of webs
> 3) continual browser and server improvements and platform support
I think this is a good list, but you may be forgetting the opportunities
for recompensing information providers. Right now, there is nothing to stop
providers from offering a subscription-only service. A related approach is
to encrypt documents and sell people decryption keys for use with suitable
browsers. There are many other possibilities such as pay as you go, which
will depend on third party billing mechanisms. It would be great to involve
the telcos and credit card companies in helping to set this up.
The affordability of creating webs is in little doubt and requires nothing
more that what is available with current billboard systems. Tools for
supporting maintenance of Web servers and caches are rapidly evolving. We
still need to make progress on URNs though.
I hope that my HTML+ browser will greatly stimulate browser developments
this year, and expect the trend to continue. As the number of browsers takes
off dramatically, it becomes a realistic proposition for commercial developpers
to provide professional tools. Some degree of continuity in standards is going
to be essential to allow commercial developpers a chance though.
> How do I see this impacting the design of HTML+?
> * expressive - every company has an "corporate identity", every publisher
> has their "look". We need style sheets if we keep the language
> semantic (and I hope we do). We could also use an style element
> like the Table of Semantic Styles in SDL.
You can see this now, in the way people are using graphics to embellish their
documents. I am currently proposing an extension that would allow authors to
customise a document toolbar in this way for this very reason. I believe that
styles shouldn't be part of the document directly though. Instead it seems
preferable to link the HTML document to stylesheets and to allow the opportunity
for servers to send stylesheets appropriate to each class of browser. This
makes for a much cleaner design, considering the very wide range of browser
platforms.
> * programmable and portable - document publishers have to know what is
> widely supported and what is not. (the same phenomena as PC software)
HTML is already very good at this - browsers are available for a staggering
number of platforms. HTML+ will soon follow suit. HTML+ will be more portable
than HTML as you won't need to translate tables and math into inline images etc.
> * linkage - lots of consideration needs to go into links. The maintenance
> of links is a real problem in my community (online UNIX technical
> document publishers). At least one level of abstraction should be
> required and specified.
By using URNs we can decouple this from the document format itself. I have
recently posted a note on how this can be achieved using a DNS like
distributed name lookup scheme for lifetime identifiers and a mechanism for
selecting between variants. This could be available by the end of this year.
Regards,
Dave Raggett,
-----------------------------------------------------------------------------
Hewlett Packard Laboratories, +44 272 228046
Bristol, England dsr@hplb.hpl.hp.com