W3C home > Mailing lists > Public > public-html@w3.org > April 2012

[Bug 16869] New: HTML5 is missing mechanism for preventing clashes of vendor-neutral extensions

From: <bugzilla@jessica.w3.org>
Date: Thu, 26 Apr 2012 16:09:21 +0000
To: public-html@w3.org
Message-ID: <bug-16869-2495@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16869

           Summary: HTML5 is missing mechanism for preventing clashes of
                    vendor-neutral extensions
           Product: HTML WG
           Version: unspecified
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P3
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: jirka@kosek.cz
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org


Section 2.2.3 Extensibility says:

"When vendor-neutral extensions to this specification are needed, either this
specification can be updated accordingly, or an extension specification can be
written that overrides the requirements in this specification. When someone
applying this specification to their activities decides that they will
recognize the requirements of such an extension specification, it becomes an
applicable specification."

This doesn't provide flexible mechanism which can incorporate vendor-neutral
extension attributes in required speed given overhead connected with spec
update. Lightweight registry which will allow registration of vendor-neutral
attribute prefixes should be created and maintained.

I propose the following spec change. After above paragraph the following prose
will be added:

For vendor-neutral extension attributes their attribute prefix may be
registered in the Wiki Vendor-neutral extension attribute prefixes (yet to be
created if this proposal is accepted by WG).

Anyone is free to edit the Wiki Vendor-neutral extension attribute prefixes
page at any time to add a new prefix. These new prefixes must be specified with
the following information:

Prefix

The actual prefix being defined. The name should not be confusingly similar to
any other defined prefix (e.g. differing only in case).

Brief description

A short non-normative description of what attributes with the prefix do.

Specification
A link to a more detailed description of all attributes using the prefix. It
could be another page on the Wiki, or a link to an external page.

Status

One of the following:

Proposed
The prefixed set of attributes has not received wide peer review and approval.
Someone has proposed it and is, or soon will be, using it.

Ratified
The prefixed set of attributes has received wide peer review and approval. It
has a specification that unambiguously defines how to handle pages that use the
prefixed set of attributes, including when they use it in incorrect ways.

If a prefixed set of attributes is registered in the "proposed" state for a
period of a month or more without being used or specified, then it may be
removed from the registry.

Anyone can change the status at any time, but should only do so in accordance
with the definitions above.

Conformance checkers may use the information given on the Wiki Vendor-neutral
extension attribute prefixes page to establish if a prefixed attribute is
allowed or not: attributes with prefixes marked as "proposed" or "ratified"
should be accepted, whereas prefixes marked as "discontinued" or not listed in
the aforementioned page may be rejected as invalid. Conformance checkers may
cache this information (e.g. for performance reasons or to avoid the use of
unreliable network connectivity).

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Thursday, 26 April 2012 16:20:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:48 GMT