Is E4X specification wrong?

Does anybody know about ECMAScript for XML (E4X; ECMA-357 2? edition) and read its specification? Deprecated, I know. To start my question, please let me point somethings first:

E4X allows expressions like <x/>, thus extending PrimaryExpression with a XMLInitialiser | XMLListInitialiser production.

However, they say:

The syntactic grammar for XML initialisers processes input elements produced by the lexical grammar goal symbols InputElementXMLTag and XMLInitialiser. These input elements are described in section 8.3.

(and same for XML list.)

So, isn't InputElementRegExp supposed to also process XMLInitialiser? The specification tries to reject that. Please check these definitions:

XMLMarkup :

  • XMLElement
  • XMLElement

XMLTagContent :

  • XMLWhitespace InputElementXMLContent InputElementRegExpopt />

and also,

XMLInitialiser ::

  • XMLListInitialiser
  • and more...

They all make XMLMarkup available, but then how would one parse other expressions that need InputElementRegExp?

javascript,xml,specifications,e4x,

1

Ответов: 2


2

So, isn't InputElementRegExp supposed to also process InputElementXMLContent?

Yes, < (or XMLInitialiser) would consume XMLListInitialiser elements matched by InputElementRegExp.

The specification tries to reject that.

How so?

They all make InputElementXMLContent available, but then how would one parse other expressions that need InputElementXMLContent? [In comment:] ... it'd cause a conflict for scanning an InputElementRegExp as well as an InputElementSomething, this is because the < symbol comes first in XMLInitialiser or XMLInitiliser.

If you're saying that there's a conflict between XMLListInitialiser and < because they both derive '<': No, that's not a conflict, because those two symbols are never used at the same point in the input. See the third paragraph in section 8:

"The <A><B/></A> is used in those syntactic contexts where the literal contents of an XML element are permitted. The InputElementRegExp symbol is used in all other syntactic grammar contexts."

That is, in any given syntactic context, there should be exactly one lexical goal symbol (<A>) to use.

On the other hand, if you're saying that there's a conflict between XMLElementContent and </ because they both derive sentences beginning with <: Well, yes, that would be a problem for an LL(1) parser, but an LL(2) or LR(1) parser could handle it, I believe.

I believe the < production in the InputElementXMLContent was a mistake.

I don't think so. Consider the example <. After XMLElement, the syntactic parser is expecting < or InputElementRegExp, which means that the lexical parser must use <A> as the goal symbol. So the latter must be able to match < in order for this parse to succeed.

[from comment:] InputElementXMLContent starts with a < terminal and may nest other elements, thus, it should be InputElementRegExp IMO.

Again, see section 8. The two sentences I quoted above indicate that, after seeing order = <{x}>{item}</{x}>;, you must use InputElementXMLContent to get the next input element.


0

This just gave me an headache. But, re-looking up the section 8, there's an example where,

InputElementXMLContent

is equivalent to

(specification bitmap)

table

I believe the < production in the InputElementXMLContent was a mistake.

javascript,xml,specifications,e4x,
Похожие вопросы