W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2009

Re: Naming for custom/specialized extended attributes?

From: Dimitry Golubovsky <golubovsky@gmail.com>
Date: Thu, 8 Oct 2009 09:08:41 -0400
Message-ID: <bcba51a0910080608i491a516cp3309d1ea5df309b@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Cameron McCormack <cam@mcc.id.au>, public-script-coord@w3.org

On Thu, Oct 8, 2009 at 1:51 AM, Maciej Stachowiak <mjs@apple.com> wrote:
> On Oct 7, 2009, at 10:04 PM, Cameron McCormack wrote:
>> Seems like it would be a good idea to suggest a naming convention in the
>> spec (e.g. like CSS does with vendor prefixes).
> Sounds like a good idea. WebKit will likely add some extended attributes for
> Objective-C (and possibly for QObject and GObject bindings) to Web IDL once
> we adopt it, and it would be good to have a convention.

OK, let me come up with proposal. Since there is a special section 6
where custom ext. attributes are mentioned, this would be a proper
place for such clarification.

Let's add to the section 6 after "that do not conflict with those
defined in this document." BTW can we use RFC2119 modal verbs in
informative sections?


It is recommended that these vendor-specific extended attributes
syntax conform to the five productions (ExtendedAttributeNoArg to
ExtendedAttributeNamedArgList) specified in section 3.8. Extended
attribute identifiers for these vendor-specific extended attributes
SHOULD start with LATIN CAPITAL LETTER X (0058) followed by LOW LINE
(005F) and by at least one character allowed as WebIDL identifier
start, and optionally by any number of characters allowed in a WebIDL
identifier. The part of an identifier of a vendor-specific extended
attribute to the right of the LOW LINE (005F) is defined solely by
vendors, and not by this document. Interpretation of such
vendor-specific extended attributes is defined solely by vendors and
not by this document.



If we want to stay within the five productions detailed in the spec
(ExtendedAttributeNoArg to ExtendedAttributeNamedArgList) then for
attribute identifiers, we could use X_<whatevervendorspecific>, like
this (examples are completely made-up):

X_Haskell=monomorphic // matches ExtendedAttributeIdent


X_HaskellModule=::Foo::Bar // matches ExtendedAttributeScopedName

For the latter, since production for a WebIDL identifier does not
allow dots and other special characters, and many languages like
Haskell use hierarchical names, it may be agreed upon that WebIDL
scoped names would somehow translate into language-specific
hierarchical names in a vendor-specific way beyond the WebIDL spec.

Identifiers such as X_0 are not allowed (first character of an
identifier cannot be a digit).

PS I am a bit confused by the full production for an extended
attribute (section 3.8). Is there any example of an extended
attributes using e. g. curly braces as allowed by
ExtendedAttributeInner and ExtendedAttribute?

What confuses me more: even though these 5 productions can be
expressed using the general production for an extended attribute, they
are not referred to in any other production. Are these just useful
shortcuts, or there will be some simplification of the general
extended attribute syntax in the future?

Dimitry Golubovsky

Anywhere on the Web
Received on Thursday, 8 October 2009 13:09:16 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:02 UTC