Question sur la notation EBNF et JSON

Question

Récemment, j'ai étudié les parseurs et les grammaires et comment ils fonctionnent. Je lisais la grammaire formelle pour JSON au http://www.ietf.org/rfc/rfc4627.txt, qui utilise EBNF. J'étais assez confiant dans ma compréhension de BNF et EBNF, mais apparemment je ne comprends toujours pas complètement. La RFC définit un objet JSON comme ceci:

object = begin-object [ member *(value-separator member) ] 
    end-object 

je comprendre que l'intention est ici pour exprimer que tout objet JSON peut (éventuellement) avoir un élément, et ensuite être suivi par 0 ou plus (valeur-séparateur, membre) paires. Ce que je ne comprends pas, c'est pourquoi l'astérisque apparaît avant le (value-separator member). Est-ce que l'astérisque n'est pas censé imiter regex, de sorte qu'il apparaît après l'élément à répéter 0 ou plusieurs fois? Ne doit pas la grammaire de l'objet JSON être écrit comme ceci:

object = begin-object [ member (value-separator member)* ] 
    end-object 

Answer 1

La syntaxe est au sujet de la façon dont quelqu'un choisit d'écrire des entités concrètes pour représenter quelque chose.

Je suis d'accord que puttting Kleene étoiles avant l'entité répétée est non standard, et les auteurs choix à faire qui confond simplement les gens qui sont utilisés à la convention. Mais c'est parfaitement valide; les auteurs arrivent à définir ce que signifie la syntaxe, et vous, l'utilisateur de la norme, juste à l'accepter.

Il y a un certain argument pour mettre l'étoile Kleene où il a fait; il indique qu'il y a la liste suivant à un point où vous pourriez vous attendre à une liste. L'étoile de Kleene de type suffixe indique la même chose, mais c'est une sorte de surprise; d'abord vous lisez l'élément de la liste (de gauche à droite), puis vous découvrez l'étoile. En pratique, le facteur de surprise de l'étoile post-Kleene ne suffit pas en général à l'emporter sur le facteur de surprise de la convention de violation. Mais les auteurs de cette norme ont fait leur choix.

Bienvenue dans la syntaxe.

Answer 2

La bonne chose à propos des normes est qu'il y en a tellement à choisir.

Apparemment, Niklas Wirth se demandait la même chose que you thirty-some years ago:

La population de langages de programmation ne cesse de croître, et il n'y a pas fin de cette croissance vue. Beaucoup de définitions de langue apparaissent dans les revues, beaucoup se trouvent dans rapports techniques, et peut-être même un plus grand nombre reste confiné à cercles de propriété. Après exposition fréquente à ces définitions, un ne peut pas manquer de remarquer l'absence de "dénominateurs communs". Le seul fait largement accepté est que la structure de langue est définie par une syntaxe. Mais même la notation syntactique description échappe à toute forme standard convenue , bien que l'ancêtre sous-jacent est invariablement la forme Backus-Naur du rapport Algol 60. Comme variations ne sont souvent que légères, ils deviennent gênants pour leur manque de une motivation apparente.

Oui, la notation utilisée dans la RFC-4627 est moins courante, mais non incompréhensible.

Answer 3

Dans le document mentionné, http://www.ietf.org/rfc/rfc4627.txt, il est dit que

Les règles grammaticales dans le présent document doivent être interprétés comme décrit dans [RFC4234].

RFC4234 décrit ABNF (BNF Augmenté), pas EBNF. Si vous regardez à travers ce document, vous trouverez la définition suivante:

3.6. Variable Repetition: *Rule 

    The operator "*" preceding an element indicates repetition. The full 
    form is: 

     <a>*<b>element 

    where <a> and <b> are optional decimal values, indicating at least 
    <a> and at most <b> occurrences of the element. 

    Default values are 0 and infinity so that *<element> allows any 
    number, including zero; 1*<element> requires at least one; 
    3*3<element> allows exactly 3 and 1*2<element> allows one or two. 

Ainsi, la notation

*(value-separator member) 

est correct selon la définition ABNF et permet un certain nombre de répétitions, y compris zéro.