W3C home > Mailing lists > Public > www-archive@w3.org > February 2009

FW: TAG priorities: topic for discussion?

From: Larry Masinter <masinter@adobe.com>
Date: Mon, 23 Feb 2009 17:20:58 -0800
To: "www-archive@w3.org" <www-archive@w3.org>
Message-ID: <8B62A039C620904E92F1233570534C9B0118C86E2000@nambx04.corp.adobe.com>
(forwarding since previous posting was member-only)

From: Larry Masinter
Sent: Thursday, February 05, 2009 10:41 AM
To: 'tag@w3.org'
Subject: FW: TAG priorities: topic for discussion?

I wrote up some notes about what I think are some important topics for the TAG to consider.

Liaison and alignment with IETF
There can't be a separate "web" architecture and "internet" architecture. I think it is worth working toward better liaison with IETF at the IAB and IESG level, especially around the interaction of web protocols and formats and their use in other applications. For example, producing a liaison report around architectural issues, joint workshops, etc.

Liaison and alignment with other standards groups and consortia
In general, much of the work around defining the web also seems to be happening in other group, and I would urge making liaison with other groups at an architectural level a focus. The web interacts with the domain name system, the internet, the email and instant messaging infrastructure in a way that affects the users in the community, and we don't do enough to insure that someone wanting an "Internet" presence that brings together multiple technologies, including the web, have a consistent experience.

Principles
There are several areas of "goodness" which standards organizations enforce on the output of any working group, but the IETF and W3C approach these areas inconsistently and differently. For example, the IETF has a strong representation from the Internet security community and a requirement for *any* document to contain a security considerations section. On the other hand, accessibility and internationalization have a strong voice in W3C.

I hope the W3C TAG can take more of a leadership role in promoting security, internationalization, extensibility, consistency across the specifications produced by W3C.

Security
The most serious threat to the utility of the web and its ability to accomplish its objectives is the rise in threats to the security, privacy and identity of the users. I think security analysis isn't a strong suit of W3C, but I hope we might be able to improve the situation.
http://jeremiahgrossman.blogspot.com/2009/01/alignment-of-interests-in-web-security.html

Orthogonality and Independence
An important architectural principle is that standards should be written in a way that preserves the independence of the components: style sheets should be allowed to style multiple formats (CSS that's just for HTML?); domain names (domain names are not just for URLs), formats (HTML isn't just for HTTP) and protocols.  While there may well be room for applicability profiles and current practice documents which define additional behavior and constraints, the independence of technical specifications is an important architectural principle.

Overlap
Working groups will often examine existing or alternative technology and discard them for reasons of "fit": SMIL animation doesn't quite fit what is needed for HTML animation, for example. Yet we don't do enough to avoid overlap or even insist in consistency of concepts. It is unacceptable to have "resolution" expressed in different units which are difficult to translate, or different, overlapping categories of device characteristics. It is the role of the TAG to promote consistency among the various technical W3C working groups.

Fixing potholes : repair and maintenance
Many elements of the web protocol suite are in need of further development, but there is no current work on them, and, rather than addressing these existing sticky issues, working groups would rather just proceed in isolation. While this may be effective in the short run, it is ineffective in the long run. The TAG should promote and encourage areas where repair of existing specifications and attention to forgotten details (say, the "file:" URI scheme) might help resolve current problems.
Received on Tuesday, 24 February 2009 01:21:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:18:21 GMT