Jon Phipps's Library tagged w3c →  View Popular

The Web is designed to support flexible exploration of information by
human users and by automated agents. For such exploration to be
productive, information published by many different sources and for a
variety of purposes must be comprehensible to a wide range of Web client
software, and to users of that software.

HTTP and other Web technologies can be used to deploy
resource representations that are self-describing:
information about the encodings used for each representation is provided explicitly
within the representation.
Starting
with a URI, there is a standard algorithm that a user agent can apply to
retrieve and interpret such representations.
Furthermore, representations can be what we refer to as grounded
in the Web, by ensuring that specifications required to
interpret them are determined unambiguously based on the URI, and that explicit
references connect the pertinent specifications to each other.
Web-grounding ensures that the specifications needed
to interpret information on the Web can be identified unambiguously.
When such
self-describing, Web-grounded resources are linked together,
the Web as a whole can support reliable,
ad hoc discovery of information.

This finding describes how document
formats, markup conventions, attribute values, and other data formats
can be designed to facilitate the deployment of self-describing,
Web-grounded Web content.

This document surveys the problem of specifying a uniform method
for obtaining information pertaining to a resource without
necessarily having to parse a representation of the resource. It is an
attempt to rationalise several discussions that have taken place in a
variety of e-mail fora. More background and links to e-mail threads
area available on the wiki
page.

An RDFa document can use GRDDL with something like RDFa profile by Fabien Gandon.

Other custom dialects include:

This document describes widgets. It covers the packaging format, the
manifest file config.xml, and
scripting interfaces for working with widgets.

The type of widgets that are addressed by this document are usually
small client-side applications for displaying and updating remote data,
packaged in a way to allow a single download and installation on a client
machine. The widget may execute outside of the typical web browser
interface. Examples include clocks, stock tickers, news casters, games and
weather forecasters. Some existing industry solutions go by the names
"widgets", "gadgets" or "modules".

Since I worked on a browser several years ago this is an interest to me. My opinion is that the w3c is and has always been the problem. HTML is not really a spec, even if you just consider the syntax. But real problem is that HTML is a presentation language and that’s not addressed. I do remember an RFC on tables layout being referenced but the major browsers didn’t conform to it. HTML is not unique every spec I’ve seen from the w3c is poor (XML, SOAP, XML Schema….). The w3c also doesn’t seem to know how to manage a standard.

In my opinion correct standard management requires:

1. Define a specification using a defined syntax (note how w3c specs doesn’t define the BnF grammer they use, note how the IETF specs do). People find it hard to write a parser based upon paragraphs of description.

2. Define and provide conformance and validation tests for the specification. People should be able to test to see if their implementation conforms to the specification.

3. Provide a reference implementation.

4. Define and provide an interoperability suite.

5. Define a method for subsetting and extending the specification.

6. Enforce the use of the standard so that only conforming implementations exist.

This finding addresses the questions "When should URNs or URIs
with novel URI schemes be used to
name information resources for the Web?" and "Should registries be provided for
such identifiers?". The answers given are "Rarely if ever" and "Probably not". Common arguments in favor
of such novel naming schemas are examined, and their properties compared with
those of the existing http: URI scheme.

Three case studies are then presented, illustrating how the
http: URI scheme can be used to achieve many of the stated
requirements for new URI schemes.