Re: Thoughts on a new charter for HTML

Dan,

	Of course I have ideas on how these problems should be solved. I'll list
my proposed solutions here.
Once again let me say I don't really expect many others to agree. 

<DAN CONNOLLY TYPE="excerpt" Source="email:html-future@w3.org">
At 05:31 PM 5/18/98 -0500, you wrote:
>Daniel B. Austin wrote:
>>  After reading the briefing material, and looking at several previous
charter
>> documents,here are my thoughts ...
>
>> (http://www.w3.org/Style/XSL/Group/charter).
>> I'll use this as a model for a 'strawman' proposal for
>
>Excellent. Thanks for the contribution! It touches
>all the bases.
>
>My reservation with this proposal is: is it sufficiently
>specific? It looks a bit like a blank check, ala "go away
>and work for 18-24 months on making HTML better."
>
>As a former WG chair, I know the value of a specific charter,
>so that you can say "never mind about all that; it's not
>in our charter anyway."
</DAN CONNOLLY>

I agree with this 100%. This is a difficult task, which is why I suggested
24 instead of 12 months.
I am hoping others will also add to this proposal in order to flesh it out
more fully. My ideas below might provide an
adequate place to begin.

<DAN CONNOLLY TYPE="excerpt" Source="email:html-future@w3.org">
>Let's put it this way: extensibility and scalability
>are laudable goals, but they're also hard problems. I
>think a lot of folks would bet against any random group of 20 people
>who claimed to be solving these problems:
> 
>> · The extensibility problem  HTML, despite the immense effort devoted to
its
>> creation and specification, is currently lacking in the extensibility
>> necessary
>> to allow for rapidly changing web technology. This results in the misuse of
>> current markup, the addition of proprietary markup, and a general lack of

>> standardized results for web pages.
>> · The scalability problem  HTML currently does not scale well across a
diverse
>> set of display devices, either those currently available (webTV,
>> PalmPilots) or
>> those expected in the future (cell phones, automobiles, home
appliances). This
>> limits accessibility and basically confines HTML’s role to large-scale
browser
>> software suitable for personal computers.
>> · The conformance problem  due to the weaknesses of HTML and its
inability to
>> deal in a standard fashion with common publishing practices, current user
>> agents do not display the level of conformance to HTML standards desired
in a
>> structured markup environment. In many cases, a given HTML document will
>> display remarkably differently even on the same platform when displayed in
>> different clients. Also, since HTML doesn’t provide services authors
desire,
>> much of the published HTML on the web is of very low quality.
>
>Do we have some sense of the solution to these problems?
>Can we give some sense of how we're going to approach them?
>Even broad references to bodies of work that suggest
>it's a straightfoward task?
</DAN CONNOLLY>

Here are my personal suggestions on solutions to the problems I outlined
above:

Problem: extensibility of HTML to allow compatibility with new technical
developments in web publishing
Solution: 
1) rewrite HTML as an XML application 
2) modularize the DTD sensibly into component parts e.g. forms, tables,
external references, formatting etc.
as in the mehitabel project: http://www.altheim.com/specs/mehitabel/
(I don't agree with the divisions made here, but it is a place to start.
Schemas may be a better overall approach.)
3) add facilities to the language so that when new technology becomes
available it can be dropped into place
without breaking the rest of the web. There's no need to buy a new
motherboard everytime we buy a new modem...

Problem: scalability of HTML with respect to diverse display devices
Solution: define HTML in such a way that it can be profiled in the sense
that XML is a 'profile' of SGML. This 
would allow us to define HTML profiles (or subsets) appropriate for
platforms/clients with differing capabilities.
Example: we could define an HTML profile that was suitable for displays
with 16 lines or less and no formatting
beyond emphasis (for cell phones say) that was still conformant to the
specification. And another profile that provides for multimedia,
24 bit color, CSS2, full DOM compliance, etc. (for PC browsers).
Note that HTML probably cannot be everything to everyone; at some point the
needs of the authors and/or users
will exceed HTML's abilities. But we can make it a lot more inclusive
(scalable) than it is.
Note also that this may require work to be done to HTTP itself.

Problem: conformance of HTML clients to the standard
Solution: repurpose HTML toward automated generation, eliminating both
errors and perversions caused by authors desperate
to design pages for their needs and also the client vendors' advantage in
balkanizing HTML to differentiate their products.
Once again, PostScript is a key example here. Let's have the vendors
compete on providing us with useful tools, rather than 
on producing incompatible display devices, or the 'least broken
implementation'.
This also implies a standard that is well written, without loopholes, and
is narrowly defined for a specific, 
well understood purpose.
 
Overarching concepts of this proposal:
* using the right tool for the right job (HTML for layout, CSS for style,
acronymML for authoring...)
* no more human authored HTML
* a stable HTML standard (one that doesn't change before I have managed to
read the last spec... :-) )

I will look into gathering some references that pertain to this.

Regards,

D-

Received on Monday, 18 May 1998 19:05:53 UTC