xbgf.xsd

<xsd:schema
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:bgf="http://planet-sl.org/bgf"
  xmlns:ldf="http://planet-sl.org/ldf"
  xmlns:xbgf="http://planet-sl.org/xbgf"
  targetNamespace="http://planet-sl.org/xbgf">

  <xsd:annotation>
    <xsd:documentation>
      BGF transformation operator suite
    </xsd:documentation>
    <xsd:documentation>
		This chapter describes the transformational suite for BGF.
		Most of the information present here is located in the XML Schema definition of the
		language, part of the SLPS project. The rest was introduced by the language documentation
		transformation commands in the process of automated generation of the manual in its
		present form.
    </xsd:documentation>
  </xsd:annotation>
  
  <xsd:import namespace="http://planet-sl.org/bgf" schemaLocation="bgf.xsd"/>

  <xsd:element name="sequence">
    <xsd:annotation>
      <xsd:documentation>
        Sequential composition of multiple transformations.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:choice minOccurs="0" maxOccurs="unbounded">
        <xsd:group ref="xbgf:transformation"/>
        <xsd:element ref="xbgf:atomic"/>
      </xsd:choice>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="atomic">
    <xsd:annotation>
      <xsd:documentation>
        Multiple transformations that must be for some reason perceived as one step.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:group ref="xbgf:transformation" maxOccurs="unbounded"/>
    </xsd:complexType>
  </xsd:element>

  <xsd:group name="transformation">
    <xsd:annotation>
      <xsd:documentation>
        A list of all the XBGF transformations is grouped in seven categories:
        <ldf:keyword>folding-unfolding-transformation</ldf:keyword> collects those commands
        that perform the well-known folding/unfolding operations in slightly varied
        circumstances; <ldf:keyword>refactoring-transformation</ldf:keyword> contains
        transformations that perform factoring and reorganising procedures that 
        do not alter the language generated by the grammar; <ldf:keyword>increasing-transformation</ldf:keyword>
        increase the semantics of the language by adding new options and alternatives to it;
        <ldf:keyword>decreasing-transformation</ldf:keyword> similarly decrease the semantics;
        <ldf:keyword>concrete-revising-transformation</ldf:keyword> are refactorings if we use term-oriented
        semantics (abstract syntax) but they are neither semantic preserving, increasing nor decreasing
        transformations if we use string-oriented semantics (concrete syntax); transformations from
        <ldf:keyword>abstract-revising-transformation</ldf:keyword> change the language
        generated by the grammar in a way that they cannot be a priori classified as any of 
        the above; <ldf:keyword>decorative-transformation</ldf:keyword> are special refactorings
        that are used to make or destroy labels and selectors in BGF.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:choice>
      <xsd:group ref="xbgf:folding-unfolding-transformation"/>
      <xsd:group ref="xbgf:refactoring-transformation"/>
      <xsd:group ref="xbgf:increasing-transformation"/>
      <xsd:group ref="xbgf:decreasing-transformation"/>
      <xsd:group ref="xbgf:concrete-revising-transformation"/>
      <xsd:group ref="xbgf:abstract-revising-transformation"/>
      <xsd:group ref="xbgf:decorative-transformation"/>
      <!-- semantics unclear -->
      <xsd:element ref="xbgf:rename"/>
      <!-- status unclear -->
      <xsd:element ref="xbgf:reroot"/>
      <!-- deprecated -->
      <xsd:element ref="xbgf:strip"/>
      <!-- debug -->
      <xsd:element ref="xbgf:dump"/>
      <xsd:element ref="xbgf:bypass"/>
    </xsd:choice>
  </xsd:group>

  <xsd:group name="folding-unfolding-transformation">
    <xsd:annotation>
      <xsd:documentation>
        Folding and unfolding activities are the most basic ones in grammar
        transformation and the most used ones in grammar convergence. Since
        grammar comparison is done in such a way that only applies very basic
        algebraic laws in its endeavours to match the two grammars, many
        more sophisticated manipulations need to be executed semi-automatically
        in a programmable fashion. These manual steps help to establish a
        stronger link between the convergence point and the original grammar
        artifact since they aid to reveal some unapparent properties of those
        grammars.
      </xsd:documentation>
      <xsd:documentation>
        All these transformations are provably correct in the sense that
        it is possible to prove that the languages generated by the grammars
        before the transformation and after it are indeed the same. All
        refactorings are easily reversible and introduced below in pairs.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:choice>
      <xsd:element ref="xbgf:unfold"/>
      <xsd:element ref="xbgf:fold"/>
      <xsd:element ref="xbgf:inline"/>
      <xsd:element ref="xbgf:extract"/>
      <xsd:element ref="xbgf:abridge"/>
      <xsd:element ref="xbgf:detour"/>
      <xsd:element ref="xbgf:unchain"/>
      <xsd:element ref="xbgf:chain"/>
    </xsd:choice>
  </xsd:group>
  <xsd:group name="refactoring-transformation">
    <xsd:annotation>
      <xsd:documentation>
        Here is a list of the XBGF transformations that perform
        other provably semantic-preserving refactorings
      </xsd:documentation>
    </xsd:annotation>
    <xsd:choice>
      <xsd:element ref="xbgf:massage"/>
      <xsd:element ref="xbgf:distribute"/>
      <xsd:element ref="xbgf:factor"/>
      <xsd:element ref="xbgf:deyaccify"/>
      <xsd:element ref="xbgf:yaccify"/>
      <xsd:element ref="xbgf:eliminate"/>
      <xsd:element ref="xbgf:introduce"/>
      <xsd:element ref="xbgf:import"/>
      <xsd:element ref="xbgf:vertical"/>
      <xsd:element ref="xbgf:horizontal"/>
      <xsd:element ref="xbgf:equate"/>

      <xsd:element ref="xbgf:rassoc"/>
      <xsd:element ref="xbgf:lassoc"/>
      <xsd:element ref="xbgf:iterate"/>

      <xsd:element ref="xbgf:splitT"/>
    </xsd:choice>
  </xsd:group>
  <xsd:group name="increasing-transformation">
    <xsd:annotation>
      <xsd:documentation>
        Here is a list of the XBGF transformations that
        lengthen the grammar (increase semantics).
      </xsd:documentation>
    </xsd:annotation>
    <xsd:choice>
      <xsd:element ref="xbgf:add"/>
      <xsd:element ref="xbgf:appear"/>
      <xsd:element ref="xbgf:widen"/>
      <xsd:element ref="xbgf:upgrade"/>
      <xsd:element ref="xbgf:unite"/>
    </xsd:choice>
  </xsd:group>
  <xsd:group name="decreasing-transformation">
    <xsd:annotation>
      <xsd:documentation>
        Here is a list of the XBGF transformations that
        shorten the grammar (decrease semantics).
      </xsd:documentation>
    </xsd:annotation>
    <xsd:choice>
      <xsd:element ref="xbgf:remove"/>
      <xsd:element ref="xbgf:disappear"/>
      <xsd:element ref="xbgf:narrow"/>
      <xsd:element ref="xbgf:downgrade"/>
      <xsd:element ref="xbgf:split"/>
    </xsd:choice>
  </xsd:group>
  <xsd:group name="concrete-revising-transformation">
    <xsd:annotation>
      <xsd:documentation>
        We may refer to the semantics of a grammar as the language (set of strings)
        generated by the grammar, as it is common for formal languages --- for
        context-free grammars, in particular. With the string-oriented semantics
        in mind, all transformations mentioned above in folding and refactoring
        sections are semantics-preserving. To give an example where different
        semantics are needed consider the scenario of aligning a concrete and
        an abstract syntax.
      </xsd:documentation>
      <xsd:documentation>
        When necessary, we may apply the algebraic interpretation of a grammar, where
        grammar productions constitute an algebraic signature subject to a term-algebraic model.
        In this case, the terminal occurrences in any given production do no longer carry
        semantic meaning; they are part of the function symbol. (Hence, abstract and concrete
        syntaxes can be aligned now.)
      </xsd:documentation>
      <xsd:documentation>
        Some transformations that were effortlessly semantics-preserving w.r.t.
        the string-oriented semantics, require designated bijective mappings
        w.r.t. the term-oriented semantics, e.g., fold/unfold manipulations,
        but generally, the term-oriented semantics admits a larger class of
        semantics-preserving transformations than the string-oriented one.
      </xsd:documentation>
      <xsd:documentation>
        The following section gathers those transformations that would have been
        considered refactorings if we only used term-oriented semantics. From
        the string-oriented point of view they revise semantics and can be deemed
        as neither grammar lengthening nor grammar shortening transformations.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:choice>
      <xsd:element ref="xbgf:abstractize"/>
      <xsd:element ref="xbgf:concretize"/>
      <xsd:element ref="xbgf:permute"/>
    </xsd:choice>
  </xsd:group>
  <xsd:group name="abstract-revising-transformation">
    <xsd:annotation>
      <xsd:documentation>
        Some grammar differences may require more arbitrary replacements,
        that cannot be expressed as semantics-preserving even in abstract
        syntax. These include projections or injections of non-optional
        nonterminals, adding definitions for bottom nonterminals,
        performing volatile replacements.
      </xsd:documentation>
      <xsd:documentation>
        Whenever a transformation from this group is used in a convergence
        path, it signals either about a construction point where the grammar
        engineer is having a temporary shortcut to be substituted later
        with a longer sequence of more accurate manipulations, or an inevitable
        error in the BGF that needs fixing (preferably in the original
        artifact---specification, compiler sources, etc).
      </xsd:documentation>
    </xsd:annotation>
    <xsd:choice>
      <xsd:element ref="xbgf:define"/>
      <xsd:element ref="xbgf:undefine"/>
      <xsd:element ref="xbgf:redefine"/>
      <xsd:element ref="xbgf:inject"/>
      <xsd:element ref="xbgf:project"/>
      <xsd:element ref="xbgf:replace"/>
    </xsd:choice>
  </xsd:group>
  <xsd:group name="decorative-transformation">
    <xsd:annotation>
      <xsd:documentation>
        Last but not least, there are four refactorings that are
        very specific to the BGF itself. Not all grammar definition formalisms
        have labelled productions, but since we do, we also need two transformation
        steps made possible: to <ldf:keyword>designate</ldf:keyword> an already
        available production with a label, and to <ldf:keyword>unlabel</ldf:keyword>
        an existing labelled production.
	We strip selectors from subexpressions with
	<ldf:keyword>anonymize</ldf:keyword> and add
	them, naturally, with <ldf:keyword>deanonymize</ldf:keyword>.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:choice>
      <xsd:element ref="xbgf:designate"/>
      <xsd:element ref="xbgf:unlabel"/>
      <xsd:element ref="xbgf:deanonymize"/>
      <xsd:element ref="xbgf:anonymize"/>
    </xsd:choice>
  </xsd:group>

  <xsd:element name="add">
    <xsd:annotation>
      <xsd:documentation>
        Nonterminal definitions can be extended ("added to") vertically
        and horizontally. In the former case, a given production is added
        to an existing definition. In the latter case, a given branch is
        added to a given expression. The
        horizontal mode is there for convenience only because it could be
        simulated by a sequence of extraction, vertical addition, and
        inlining. There are two operators that are very similar to the
        (vertical) add operator: <ldf:keyword>define</ldf:keyword> and <ldf:keyword>introduce</ldf:keyword>. The define operator
        should be used when an the definition of an undefined nonterminal
        is added. The introduce operator should be used when a fresh
        nonterminal is to be defined.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:choice>
        <xsd:element name="vertical">
          <xsd:complexType>
            <xsd:sequence>
             <xsd:element ref="bgf:production"/>
            </xsd:sequence>
          </xsd:complexType>
        </xsd:element>
        <xsd:element name="horizontal">
          <xsd:complexType>
            <xsd:sequence>
             <xsd:element ref="bgf:production"/>
            </xsd:sequence>
          </xsd:complexType>
        </xsd:element>
      </xsd:choice>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="appear">
    <xsd:annotation>
      <xsd:documentation>
        The purpose of this transformation operator is to insert an nillable symbol (i.e.,
        reducible to an empty sequence) at any place in any existing grammar production.
        It takes a production as an input. Inside that production, one nillable subexpression
        should be marked.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="bgf:production"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="bypass">
    <xsd:annotation>
      <xsd:documentation>
		This is a special operator that does exactly nothing.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType/>
  </xsd:element>

  <xsd:element name="chain">
    <xsd:annotation>
      <xsd:documentation>
        Just like <ldf:keyword>unchain</ldf:keyword> is a specific form of <ldf:keyword>inline</ldf:keyword>,
        chaining is a disciplined form of
        <ldf:link>
          <text>extraction</text>
          <reference>extract</reference>
        </ldf:link>. The argument
        production will be part of the resulting grammar; it is a chain
        production, i.e., a production with a nonterminal as its defining
        expression. That nonterminal is the one whose definition is to be
        extracted. That definition is the defining expression of the
        production (from the input grammar) whose defined nonterminal and
        label (if any) matches with the argument production.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="bgf:production"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="deanonymize">
    <xsd:annotation>
      <xsd:documentation>
        While labels are only used to name individual productions,
        selectors can name arbitrary parts of any BGF expression.
        This command allows to add a selector to the existing production.
        To avoid disambiguations, the whole production is required
        as an argument, with the newly introduced part being marked.        
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="bgf:production"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="define">
    <xsd:annotation>
      <xsd:documentation>
        An undefined nonterminal is resolved by this operator. The nonterminal must be in
        use. The introduce operator should be used when a fresh nonterminal
        is to be defined. The add operator should be used when an existing
        definition is to be extended.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="bgf:production" maxOccurs="unbounded"/>
      </xsd:sequence>
      <xsd:attribute name="tag" type="xsd:string"/>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="disappear">
    <xsd:annotation>
      <xsd:documentation>
        This operator behaves like <ldf:keyword>project</ldf:keyword>, but only allows for nillable elements (optional, star) to disappear.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="bgf:production"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="downgrade">
    <xsd:annotation>
      <xsd:documentation>
        Replaces a nonterminal with one of its definitions.
        The first parameter is the scope production with one of the nonterminals marked.
        The second parameter is one of that nonterminal's definitions,
        which right hand side will be used for replacement.
      </xsd:documentation>
      <xsd:documentation>
        The XBGF processor looks for the first production with the marked part (but without the markers).
        If it is found, the marked part is replaced with the right hand side of the second argument
        production.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="bgf:production"/>
        <xsd:element ref="bgf:production"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="designate">
    <xsd:annotation>
      <xsd:documentation>
        An unlabeled production is labeled. The argument production is
        the intended result, i.e., the labeled production---the transformation
        refuses to work if the argument production contains no label.
      </xsd:documentation>
      <xsd:documentation>
        Labelling transformations serve two roles usually: they can be used
        directly to make the labels in both grammars agree so that they can
        converge; or they are used to mark the target for the transformations
        that follow them and perform local manipulations.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="bgf:production"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="unlabel">
    <xsd:annotation>
      <xsd:documentation>
        This is a reverse of <ldf:keyword>designate</ldf:keyword> that strips an existing production from a label.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="label" type="bgf:label"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="deyaccify">
    <xsd:annotation>
      <xsd:documentation>
		Deyaccification is a widely used term that means converting recursive
		definitions to iterative ones where possible. The name comes from
		YACC, or Yet Another Compiler Compiler, a tool which underlying parsing
		technology limits were enforcing the usage of recursive definitions back in the 1970s.
		However, it somehow became common practice to remain within them
		even when grammar engineers do not use yacc as such at all.
      </xsd:documentation>
      <xsd:documentation>
        The name of a nonterminal must be provided as an argument, then
        the transformation engine checks if the grammar productions for this
        nonterminal fit into one of the yaccified patterns. If not, the error
        is reported, otherwise the definition is replaced by one that uses
        regular expression operators instead of epsilon, choice,
        and recursion.
      </xsd:documentation>
      <xsd:documentation>
        Both left- and right-recursive forms can be factored with this transformation.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="nonterminal" type="bgf:nonterminal"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="distribute">
    <xsd:annotation>
      <xsd:documentation>
        Distribute sequential composition over choices so that choices
        are pulled out of sequences. The transformation
        is either attempted for all productions of a nonterminal or for a
        specific one appointed by its label.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:group ref="xbgf:scope"/>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="dump">
    <xsd:annotation>
      <xsd:documentation>
        This is a debugging tool for XBGF. When the <ldf:keyword>dump</ldf:keyword> command is encountered,
        the transformation sequence stops and the grammar in its
        current state is dumped to the file xbgf.log.
      </xsd:documentation>
      <xsd:documentation>
        The contents of xbgf.log can be used as an input for grammar
        comparator or for copy-pasting productions and expressions
        from the grammar to the construction point of the XBGF sequence.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType/>
  </xsd:element>

  <xsd:element name="eliminate">
    <xsd:annotation>
      <xsd:documentation>
        An unused definition (at most used within the definition itself)
        is removed. The <ldf:keyword>undefine</ldf:keyword> operator
        should be utilised instead when the definition must be removed despite
        remaining uses. The <ldf:keyword>remove</ldf:keyword> operator
        should be utilised instead when only part of the definition (i.e.,
        a production of a vertical definition) is  to be removed.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="nonterminal" type="bgf:nonterminal"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="extract">
    <xsd:annotation>
      <xsd:documentation>
        A new definition is introduced by extraction. The argument provided for this
        transformation
        is a production that identifies both the fresh nonterminal to be introduced and the
        expression that is used both as a pattern for folding and as a right hand side of
        the added definition.
        An optional scope can limit the application
        of the folding part of the extraction transformation to a
        specific production or a specific nonterminal.
      </xsd:documentation>
      <xsd:documentation>
        If the nonterminal defined by the argument production is
        already mentioned (i.e., defined or referenced) in the current
        grammar, the transformation refuses to work and reports an
        error. This usually signals an error in the language engineer's
        logic because the existing traces of a possibly similar nonterminal
        conflict with the definition that is being introduced.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="bgf:production"/>
        <xsd:element name="in" minOccurs="0">
          <xsd:complexType>
            <xsd:group ref="xbgf:scope"/>
          </xsd:complexType>
        </xsd:element>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="factor">
    <xsd:annotation>
      <xsd:documentation>
        Massage modulo factorisation over choices. The transformation
        is either attempted for all productions of a nonterminal or for a
        specific one appointed by its label.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="bgf:expression"/>
        <xsd:element ref="bgf:expression"/>
        <xsd:element name="in" minOccurs="0">
          <xsd:complexType>
            <xsd:group ref="xbgf:scope"/>
          </xsd:complexType>
        </xsd:element>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="fold">
    <xsd:annotation>
      <xsd:documentation>
        Folding replaces every expression that matches with the right hand
        side of the given nonterminal's definition with the nonterminal
        itself. As with <ldf:keyword>unfold</ldf:keyword>,
        <ldf:keyword>fold</ldf:keyword> works on the scope of the grammar,
        and its impact can be limited to one labelled production or to
        all the productions belonging to one nonterminal. Regardless
        of the specified scope, folding is not applied to the definition
        of the argument nonterminal.
      </xsd:documentation>
      <xsd:documentation>
        Since this transformation strives to preserve the language, it needs
        a horizontal definition to work. When only one of several existing
        definitions is used for folding, it would actually increase the semantics
        of the language after transformation---the corresponding XBGF command
        is called <ldf:keyword>upgrade</ldf:keyword>.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="nonterminal" type="bgf:nonterminal"/>
        <xsd:element name="in" minOccurs="0">
          <xsd:complexType>
            <xsd:group ref="xbgf:scope"/>
          </xsd:complexType>
        </xsd:element>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="horizontal">
    <xsd:annotation>
      <xsd:documentation>
        Turn a definition based on multiple productions into a top choice-based one.
        The action is a reverse of <ldf:keyword>vertical</ldf:keyword>.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="nonterminal" type="bgf:nonterminal"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="inject">
    <xsd:annotation>
      <xsd:documentation>
        The argument production defines the intended result of the
        transformation --- a production that has additional components
        in the sequential composition, when compared to the corresponding
        production in the input grammar with the same defined nonterminal
        and the same label, if any.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:choice>
        <xsd:element ref="bgf:production"/>
      </xsd:choice>
      <xsd:attribute name="tag" type="xsd:string"/>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="inline" type="bgf:nonterminal">
    <xsd:annotation>
      <xsd:documentation>
        When this transformation is performed, an existing definition is eliminated by inlining.
        This means that the argument nonterminal identifies the (horizontal) definition
        that is to be unfolded and stripped away from the grammar.
      </xsd:documentation>
      <xsd:documentation>
        The semantics of <ldf:keyword>inline</ldf:keyword> is that of a sequential composition of
        <ldf:keyword>unfold</ldf:keyword> and <ldf:keyword>eliminate</ldf:keyword>.
      </xsd:documentation>
    </xsd:annotation>
  </xsd:element>

  <xsd:element name="introduce">
    <xsd:annotation>
      <xsd:documentation>
        A definition of a fresh nonterminal is added. The <ldf:keyword>add</ldf:keyword>
        operator should be used instead, if the nonterminal is already defined,
        is to be merely extended. The <ldf:keyword>define</ldf:keyword> operator
        should be used instead, if the nonterminal is readily in use, but merely
        lacks a definition.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="bgf:production" maxOccurs="unbounded"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="import">
    <xsd:annotation>
      <xsd:documentation>
        Allows to import another grammar: the nonterminals within it can
        refer to one another, but none of the existing productions are allowed
        to refer to them before this transformation takes place.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="bgf:production" maxOccurs="unbounded"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="iterate">
    <xsd:annotation>
      <xsd:documentation>
        The reverse of <ldf:keyword>rassoc</ldf:keyword>/<ldf:keyword>lassoc</ldf:keyword>.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:choice>
        <xsd:element ref="bgf:production"/>
      </xsd:choice>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="lassoc">
    <xsd:annotation>
      <xsd:documentation>
        The same as <ldf:keyword>rassoc</ldf:keyword>, but replaces an iterative production found in the grammar
        by a left associative repeating equivalent. The ``l'' in ``lassoc'' refers to the
        intended effect at the level of derivation trees: the list of
        subtrees is to be converted into a nested binary tree in a
        left-associative manner.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:choice>
        <xsd:element ref="bgf:production"/>
      </xsd:choice>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="massage">
    <xsd:annotation>
      <xsd:documentation>
        The grammar is rewritten by local transformations such that
        the language generated by the grammar (or the denotation according
        to any other semantics for that matter) is preserved. The known
        rewriting rules affect the use of selectors and regular expression
        operators: e.g., any symbol will always generate the same set of strings
        that the same symbol wrapped in a selector.
      </xsd:documentation>
      <xsd:documentation>
        There are two expression arguments: one to be matched,
        and another one that replaces the matched expression.
        One of them must be in a ``massage relation'' to the other.
      </xsd:documentation>
      <xsd:documentation>
        The scope of
        the transformation can be limited.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="bgf:expression"/>
        <xsd:element ref="bgf:expression"/>
        <xsd:element name="in" minOccurs="0">
          <xsd:complexType>
            <xsd:group ref="xbgf:scope"/>
          </xsd:complexType>
        </xsd:element>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="narrow">
    <xsd:annotation>
      <xsd:documentation>
        The grammar is rewritten by local transformations such that
        the language generated by the grammar (or the denotation according
        to any other semantics for that matter) is decreased. The known
        rewriting rules affect the use of epsilon and regular expression
        operators. There are two expression arguments: one to be matched,
        and another one that replaces the matched expression. The scope of
        the transformation can be limited.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="bgf:expression"/>
        <xsd:element ref="bgf:expression"/>
        <xsd:element name="in" minOccurs="0">
          <xsd:complexType>
            <xsd:group ref="xbgf:scope"/>
          </xsd:complexType>
        </xsd:element>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="permute">
    <xsd:annotation>
      <xsd:documentation>
        The argument production defines the intended result of the
        transformation --- a production that has the same components
        in the sequential composition, but in a different order, when
        compared to the corresponding production in the input grammar
        with the same defined nonterminal and the same label, if any.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:choice>
        <xsd:element ref="bgf:production"/>
      </xsd:choice>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="project">
    <xsd:annotation>
      <xsd:documentation>
        The argument production defines the intended result of the
        transformation --- a production that has fewer components
        in the sequential composition, when compared to the corresponding
        production in the input grammar with the same defined nonterminal
        and the same label, if any.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:choice>
        <xsd:element ref="bgf:production"/>
      </xsd:choice>
      <xsd:attribute name="tag" type="xsd:string"/>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="rassoc">
    <xsd:annotation>
      <xsd:documentation>
        This transformation operator replaces an iterative production found in the grammar
        by the argument production, which is a right associative repeating equivalent of
        the former. Its defining expression involves a pattern of binary recursion
        with regard to the defined nonterminal. The ``r'' in ``rassoc'' refers to the
        intended effect at the level of derivation trees: the list of subtrees is to be
        converted into a nested binary tree in a right-associative manner.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:choice>
        <xsd:element ref="bgf:production"/>
      </xsd:choice>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="redefine">
    <xsd:annotation>
      <xsd:documentation>
        Redefine is a <ldf:keyword>replace</ldf:keyword> variant that works on production level. When this
        transformation is executed, all current productions for the
        nonterminal are dropped, and all the given ones are added
        to the grammar.
      </xsd:documentation>
      <xsd:documentation>
        This transformation is nothing more than syntactic sugar
        for an <ldf:keyword>undefine</ldf:keyword> followed directly
        with <ldf:keyword>define</ldf:keyword>. Having it as a separate
        type of transformation allows to more clearly distinguish
        completing the grammar with absent definitions (usually as
        initial correction step) and brutal nonterminal-level replacements
        (semantic revising).
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="bgf:production" maxOccurs="unbounded"/>
      </xsd:sequence>
      <xsd:attribute name="tag" type="xsd:string"/>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="remove">
    <xsd:annotation>
      <xsd:documentation>
        Productions can be removed from existing, vertical definitions.
        The remaining definition must not become empty, i.e., undefined.
        There is the undefine operator that can be applied in that case.
        There is also a horizontal mode of removing branches from choices.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:choice>
        <xsd:element name="vertical">
          <xsd:complexType>
            <xsd:sequence>
             <xsd:element ref="bgf:production"/>
            </xsd:sequence>
          </xsd:complexType>
        </xsd:element>
        <xsd:element name="horizontal">
          <xsd:complexType>
            <xsd:sequence>
             <xsd:element ref="bgf:production"/>
            </xsd:sequence>
          </xsd:complexType>
        </xsd:element>
      </xsd:choice>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="rename">
    <xsd:annotation>
      <xsd:documentation>
        Labels, nonterminals, selectors and terminals can be renamed.
        Being in line with the fundamental notion of renaming, such
        renaming must be done consistently throughout the entire grammar,
        without introducing any clashes. There is one justifiable
        exception. That is, arguably, the scope of selectors is the
        level of production as opposed to necessarily the entire grammar.
        Hence, selectors can be renamed in such a scope, optionally.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:choice>
        <xsd:element name="label">
          <xsd:complexType>
            <xsd:sequence>
              <xsd:element name="from" type="bgf:label"/>
              <xsd:element name="to" type="bgf:label"/>
            </xsd:sequence>
          </xsd:complexType>
        </xsd:element>
        <xsd:element name="nonterminal">
          <xsd:complexType>
            <xsd:sequence>
              <xsd:element name="from" type="bgf:nonterminal"/>
              <xsd:element name="to" type="bgf:nonterminal"/>
            </xsd:sequence>
          </xsd:complexType>
        </xsd:element>
        <xsd:element name="selector">
          <xsd:complexType>
            <xsd:sequence>
              <xsd:element name="in" minOccurs="0" type="bgf:label"/>
              <xsd:element name="from" type="bgf:selector"/>
              <xsd:element name="to" type="bgf:selector"/>
            </xsd:sequence>
          </xsd:complexType>
        </xsd:element>
        <xsd:element name="terminal">
          <xsd:complexType>
            <xsd:sequence>
              <xsd:element name="from" type="bgf:terminal"/>
              <xsd:element name="to" type="bgf:terminal"/>
            </xsd:sequence>
          </xsd:complexType>
        </xsd:element>
      </xsd:choice>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="replace">
    <xsd:annotation>
      <xsd:documentation>
        This operator provides a last resort to grammar editing. It
        basically provides access to free editing without any semantically
        meaningful preconditions. There are two expression arguments:
        one to be matched, and another one that replaces the matched
        expression. The scope of the transformation can be limited.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="bgf:expression"/>
        <xsd:element ref="bgf:expression"/>
        <xsd:element name="in" minOccurs="0">
          <xsd:complexType>
            <xsd:group ref="xbgf:scope"/>
          </xsd:complexType>
        </xsd:element>
      </xsd:sequence>
      <xsd:attribute name="tag" type="xsd:string"/>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="reroot">
    <xsd:annotation>
      <xsd:documentation>
        Redefine the roots (start symbols) of the grammar.
        The empty set of roots is interpreted to abbreviate the
        complete set of nonterminals used or defined by a grammar.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="root" type="bgf:nonterminal" minOccurs="0" maxOccurs="unbounded"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="abridge">
    <xsd:annotation>
      <xsd:documentation>
        Given a reflexive chain production, i.e., a production whose
        defined nonterminal equals its body, this production is simply
        removed from the grammar, even if it contains some potentially
        valuable information (like labels and selectors).
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="bgf:production"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="detour">
    <xsd:annotation>
      <xsd:documentation>
        A reverse of <ldf:keyword>abridge</ldf:keyword> that can introduce
        a reflexive chain production.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="bgf:production"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="strip">
    <xsd:annotation>
      <xsd:documentation>
        Various details of productions can be stripped with this transformation.
        In detail, one can strip labels, terminals, and selectors.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:choice>
        <xsd:element name="label" type="bgf:label">
          <xsd:annotation>
            <xsd:documentation>
              Stripping a label means that a production that uses the
              label becomes unlabeled.
            </xsd:documentation>
          </xsd:annotation>
        </xsd:element>
        <xsd:element name="allLabels">
          <xsd:annotation>
            <xsd:documentation>
              Stripping all labels means that all productions become unlabeled.
            </xsd:documentation>
          </xsd:annotation>
          <xsd:complexType/>
        </xsd:element>
        <xsd:element name="selector" type="bgf:selector">
          <xsd:annotation>
            <xsd:documentation>
              Stripping a selector s means that any occurrence of the
              selector disappears.
            </xsd:documentation>
          </xsd:annotation>
        </xsd:element>
        <xsd:element name="allSelectors">
          <xsd:annotation>
            <xsd:documentation>
              Stripping all selectors.
            </xsd:documentation>
          </xsd:annotation>
          <xsd:complexType/>
        </xsd:element>
        <xsd:element name="terminal" type="bgf:terminal">
          <xsd:annotation>
            <xsd:documentation>
              Stripping a terminal means that any occurrence of the
              terminal disappears as if the terminal denoted epsilon.
            </xsd:documentation>
          </xsd:annotation>
        </xsd:element>
        <xsd:element name="allTerminals">
          <xsd:annotation>
            <xsd:documentation>
              Stripping all terminals.
            </xsd:documentation>
          </xsd:annotation>
          <xsd:complexType/>
        </xsd:element>
      </xsd:choice>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="concretize">
    <xsd:annotation>
      <xsd:documentation>
        Just as <ldf:keyword>abstractize</ldf:keyword> is a preconditioned
        version of <ldf:keyword>project</ldf:keyword>, this operator is a variation of
        <ldf:keyword>inject</ldf:keyword>. The XBGF engine checks if the marked part only consists of
        terminal symbols: if yes, injection happens; if not, the transformation is unapplicable.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:choice>
        <xsd:element ref="bgf:production"/>
      </xsd:choice>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="unchain">
    <xsd:annotation>
      <xsd:documentation>
        Unchaining is a disciplined form of
        <ldf:link>
          <text>inlining</text>
          <reference>inline</reference>
        </ldf:link>. The argument
        production must occur in the input grammar, and it must be a chain
        production, i.e., a production with a nonterminal as its
        defining expression. The latter nonterminal is the one whose
        definition is to be inlined; it must not have any occurrences
        except in the chain production at hand.
      </xsd:documentation>
      <xsd:documentation>
        The unchain transformation does not increase the expressivity
        of the transformational language: technically, it is
        nothing more than an inline with a precondition. However, this
        particular precondition seems useful and not uncommon when dealing
        with layered grammars.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:choice>
        <xsd:element ref="bgf:production"/>
      </xsd:choice>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="undefine">
    <xsd:annotation>
      <xsd:documentation>
        This operator allows to undefine a nonterminal, i.e., remove all its productions. The
        nonterminal must have using occurrences elsewhere than just in
        its own definition. If there are no such using occurrences, then
        the less disruptive eliminate operator is to be used.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="nonterminal" type="bgf:nonterminal" maxOccurs="unbounded"/>
      </xsd:sequence>
      <xsd:attribute name="tag" type="xsd:string"/>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="unfold">
    <xsd:annotation>
      <xsd:documentation>
        The most basic unfolding transformation searches the scope for all the instances
        of the given nonterminal usage and replaces such occurrences with the
        defining expression of that nonterminal. By default the scope of the
        transformation is the full grammar, but it can be limited to all the
        definitions of one nonterminal or to one labelled production. Regardless
        of the specified scope, unfolding is not applied to the definition
        of the argument nonterminal.
      </xsd:documentation>
      <xsd:documentation>
        The definition that is being unfolded is assumed to be horizontal,
        i.e. to consist of one single production. See the section on refactorings
        for more information about horizontal and vertical definitions.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="nonterminal" type="bgf:nonterminal"/>
        <xsd:element name="in" minOccurs="0">
          <xsd:complexType>
            <xsd:group ref="xbgf:scope"/>
          </xsd:complexType>
        </xsd:element>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="unite">
    <xsd:annotation>
      <xsd:documentation>
        Two nonterminals, say x and y, are merged (possibly recursively).
        That is, the definitions of x and y (i.e., their productions)
        are merged in one definition while preserving the nonterminal y
        and replacing all occurrences of x (in the definition of x and
        anywhere else) by y.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="add" type="bgf:nonterminal"/>
        <xsd:element name="to" type="bgf:nonterminal"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="split">
    <xsd:annotation>
      <xsd:documentation>
        The reverse of <ldf:keyword>unite</ldf:keyword>.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="nonterminal" type="bgf:nonterminal"/>
        <xsd:element ref="bgf:production" maxOccurs="unbounded"/>
        <xsd:group ref="xbgf:scope"  minOccurs="0"  maxOccurs="unbounded"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="splitT">
    <xsd:annotation>
      <xsd:documentation>
        The reverse of <ldf:keyword>concatT</ldf:keyword>.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="terminal" type="bgf:terminal"/>
        <xsd:element name="into">
          <xsd:complexType>
            <xsd:sequence>
              <xsd:element name="terminal" type="bgf:terminal" maxOccurs="unbounded"/>
            </xsd:sequence>
          </xsd:complexType>
        </xsd:element>
        <xsd:element name="in" minOccurs="0">
          <xsd:complexType>
            <xsd:group ref="xbgf:scope"/>
          </xsd:complexType>
        </xsd:element>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="equate">
    <xsd:annotation>
      <xsd:documentation>
        Two nonterminals, say x and y, are merged, if their definitions are identical.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="align" type="bgf:nonterminal"/>
        <xsd:element name="with" type="bgf:nonterminal"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="abstractize">
    <xsd:annotation>
      <xsd:documentation>
        As <ldf:keyword>project</ldf:keyword>, but with an additional precondition
        that the part to be removed should consist of terminals. This is checked
        automatically by the XBGF engine: if the precondition fails, the transformation
        is inapplicable.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="bgf:production"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="anonymize">
    <xsd:annotation>
      <xsd:documentation>
        This operator is the reverse of <ldf:keyword>deanonymize</ldf:keyword> that strips one (marked) selector
        from an existing definition.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="bgf:production"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="vertical">
    <xsd:annotation>
      <xsd:documentation>
        Turn top-level choices into multiple productions. The transformation
        is either attempted for all productions of a nonterminal or for a
        specific one appointed by its label.
		The action is a reverse of <ldf:keyword>horizontal</ldf:keyword>.
    </xsd:documentation>
	<xsd:documentation>
		Occasionally we use terms ``vertical'' productions or nonterminals
		and ``horizontal'' ones. By vertical nonterminals we mean those that
		are defined by a list of productions, with every production lacking
		a top-level choice. A horizontal nonterminal, on the other hand,
		is defined by one production that is a top-level choice. Nonterminals
		that employ both top-level choices and splitting into multiple productions
		are neither horizontal nor vertical.
	</xsd:documentation>
	<!--
	<xsd:documentation>
		By default all operators prefer vertical productions. However,
		in some cases like 
        <ldf:link>
          <text>factoring</text>
          <reference>factor</reference>
        </ldf:link>
		it should not be expected from the transformation engine to look up
		scattered definitions, so one horizontal production is expected instead.
	</xsd:documentation>
	-->
    </xsd:annotation>
    <xsd:complexType>
      <xsd:group ref="xbgf:scope"/>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="widen">
    <xsd:annotation>
      <xsd:documentation>
        The grammar is rewritten by local transformations such that
        the language generated by the grammar (or the denotation according
        to any other semantics for that matter) is increased. The known
        rewriting rules affect the use of epsilon and regular expression
        operators. There are two expression arguments: one to be matched,
        and another one that replaces the matched expression. The scope of
        the transformation can be limited.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="bgf:expression"/>
        <xsd:element ref="bgf:expression"/>
        <xsd:element name="in" minOccurs="0">
          <xsd:complexType>
            <xsd:group ref="xbgf:scope"/>
          </xsd:complexType>
        </xsd:element>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="yaccify">
    <xsd:annotation>
      <xsd:documentation>
        This transformation is the reverse of <ldf:keyword>deyaccify</ldf:keyword>.
        The productions provided as arguments must be yaccified with respect to the
        actual content of the grammar. If the deyaccification process on them is
        successful and yields the production that can be found in the grammar, it
        is removed and replaced by these simpler definitions of an optional
        or repeating nonterminal, given in BNF-only expressiveness.
      </xsd:documentation>
      <xsd:documentation>
        Some complex <ldf:keyword>yaccify</ldf:keyword> cases require prior
        use of extract for introduction of an nonterminal for the optional
        or repeating phrase.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="bgf:production" maxOccurs="unbounded"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

  <xsd:element name="upgrade">
    <xsd:annotation>
      <xsd:documentation>
		Upgrading is a special variation of replacement and a slightly more
		powerful and liberal form of <ldf:link>
          <text>folding</text>
          <reference>fold</reference>
        </ldf:link>.
        This operator replaces an expression by a nonterminal that can be evaluated to it.
        The first parameter is the scope production with an expression marked.
        The second parameter is one of that nonterminal's definitions,
        which right hand side equals that expression.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="bgf:production"/>
        <xsd:element ref="bgf:production"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

  <xsd:group name="scope">
    <xsd:annotation>
      <xsd:documentation>
        Several transformation operators are possibly restricted to
        a specific scope as opposed to their application to the full
        input grammar. Two major forms of scope can be identified.
        First, a production can be appointed by its label. Second, a
        definition (nonterminal) can be appointed by its defined
        nonterminal. Arguably, one may want to be able to appoint a
        production even when it is not labeled, but a prior designate
        transformation can then be used in order to attach a label
        to the production in question.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:choice>
      <xsd:element name="label" type="bgf:label"/>
      <xsd:element name="nonterminal" type="bgf:nonterminal"/>
    </xsd:choice>
  </xsd:group>

</xsd:schema>