Re[2]: HTML WG Obsolete?

[email protected]
Thu, 21 Sep 1995 09:44:50 -0500 (EST)


About this question:

> ___ ___
>/ __/ __ Grzesiek Staniak - [email protected]
>| (_ \__ \ - http://www.lublin.pl/~gstaniak/
>\___|___/ ****___Speaking for myself, not the university___****
>
>I don't know much about how WGs work, but is it thinkable for HTML
>WG to actively search a vendor that would implement the standard and
>start co-operating with them? I mean something like exchanging a
>"HTML WG Seal of Approval" for a guarantee of following HTML 3.0
>faithfully and consulting the WG before changes in implementation.
>Does that sound feasible? From the vendors' point of view
>conformance to the standard could make a great marketing strategy -
>changes in information technology happen so fast these days, and I'm
>sure people would gladly welcome a product that by virtue of
>implementing a stable standard promises to be useful for a couple of
>months at
>least :). They could stress the profits from using a HTML 3.0 browser
>"as opposed to ordinary browsers that use inferior proprietary
>solutions". It could work.

I agree that this is a really good idea, but there is one big thing standing in
the way from the vendor's point of view - the standards process. You see to
remain competitive, a vendor has to constantly add more value to the product.
Companies like Netscape don't have the ability to wait until the internet-draft
is approved as a standard. They also can't afford to implement and re-implement
to support every little item which gets added (then changed, then removed, then
added again, etc.) to the draft. They need something solid. If we want a
vendor to work with us, we'll need to change the standards process to a much
more incremental process.

If we want to pursue getting a vendor to work with us, I propose that we modify
the process for approving this standard to a much more incremental approach. I
suggest that we break out every suggested change into a separate change proposal
(change proposals will need an independent numbering system). Then each change
proposal can be approved or disapproved independently. When a change proposal
is approved, that change should immediately be considered part of the standard
and the revision number of the standard should be increased by one. Changing
the release number of the standard should be the result of a change request. An
approved request to change the release number would increment the release number
by one and would set the revision number back to zero.

If we use this kind of process, we can still be looking at a couple of hundred
things, but we will still be making steady progress that vendors can rely on.
That will let them implement as we go to support the new features we've added,
and they can feel assured that we won't pull the rug out from under them at the
last minute.

I realize that this will add to the administrative work which must be done on
the standards development side, but I think the benefits justify it.

(I'm sure I dont' really need to ask this question, but to make it official:)
What does everyone think about this idea? I'd appreciate it if at least one
person from W3 and one person representing a vendor replied to this.

Thanks,

Anthony Lung