W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2014

[Bug 24959] "Exposed=Window,Worker" will be parsed to 2 extended attributes

From: <bugzilla@jessica.w3.org>
Date: Fri, 02 May 2014 02:30:03 +0000
To: public-script-coord@w3.org
Message-ID: <bug-24959-3890-zBzn7r7zOe@http.www.w3.org/Bugs/Public/>

Nils Barth <nbarth+w3bugzilla@google.com> changed:

           What    |Removed                     |Added
                 CC|                            |nbarth+w3bugzilla@google.co
                   |                            |m

--- Comment #1 from Nils Barth <nbarth+w3bugzilla@google.com> ---
I believe that the issue is that extended attribute phrase grammar is
*context-sensitive*, specifically due to collision of , as a extended attribute
separator  (*between* extended attributes) and as an identifier separator
(*within* an extended attribute).

Cameron, is this intended?

This makes parsing extended attributes *much* more difficult, because we need
to do it during semantic analysis, not during parsing.

Consider supporting both [Exposed=Window,Worker] and [Global]
(grammar-wise: these are both valid interface extended attributes).

Writing this as:
...is ambiguous, and requires complex semantic analysis just to *parse*.

Writing this as:
[Exposed=Window,Worker, Global]
...seems to disambiguate, but requires white space to be significant.

Using a different separator fixes this:

In Blink we've been using | for extended attribute value separators, so we'd
write this as:

...or actually (style-wise):
] interface Foo { ... };

Specifically, the problem is with the production rule
which allows one to write [Exposed=Window,Worker]

It's currently used for 3 extended attributes:
[Exposed], [Global], and [PrimaryGlobal]

The underlying issue is that the extended attribute phrase grammar is
*context-sensitive*, and thus needs to be parsed during semantic analysis.

This is stated at:
Any extended attribute encountered in an IDL fragment is matched against the
following six grammar symbols to determine which form (or forms) it is in:
Each extended attribute definition will state which of the above six forms are
I.e., the phrase grammar depends on the ExtendedAttribute (the value of the

This is *not* a serious issue for argument lists, like [Constructor(foo x, bar
y)], since the () delimiters set this off, allowing context-free parsing.

However, for bare identifier lists, this causes parsing problems.

Could we change this?

You are receiving this mail because:
You are on the CC list for the bug.
Received on Friday, 2 May 2014 02:30:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:21 UTC