CODEWITHSUNDEEP
javascriptxmlspecificationse4x
user5066707
user5066707

Reputation:

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 InputElementXMLContent. These input elements are described in section 8.3.

(and same for XML list.)

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

XMLInitialiser :

XMLElement :

and also,

InputElementXMLContent ::

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

Upvotes: 1

Views: 225

Answers (2)

Michael Dyck
Michael Dyck

Reputation: 2458

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

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

The specification tries to reject that.

How so?

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

If you're saying that there's a conflict between InputElementRegExp and InputElementXMLContent 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 InputElementXMLContent 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 (InputElementSomething) to use.

On the other hand, if you're saying that there's a conflict between XMLInitiliser and XMLListInitialiser 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 <A><B/></A>. After <A>, the syntactic parser is expecting XMLElementContent or </, which means that the lexical parser must use InputElementXMLContent as the goal symbol. So the latter must be able to match < in order for this parse to succeed.

[from comment:] XMLElement 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 <A>, you must use InputElementXMLContent to get the next input element.

Upvotes: 1

user5066707
user5066707

Reputation:

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

order = <{x}>{item}</{x}>;

is equivalent to

(specification bitmap)

table

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

Upvotes: 0

Related Questions