Skip to content

Commit

Permalink
Browse files Browse the repository at this point in the history
XBGF and XLDF closer to perfection
git-svn-id: https://slps.svn.sourceforge.net/svnroot/slps@492 ab42f6e0-554d-0410-b580-99e487e6eeb2
  • Loading branch information
grammarware committed Feb 24, 2009
1 parent 6e73d38 commit 22e4839
Show file tree
Hide file tree
Showing 8 changed files with 879 additions and 378 deletions.
223 changes: 114 additions & 109 deletions shared/xsd/ldf.xsd
Expand Up @@ -57,6 +57,7 @@
<xsd:element name="p" type="xsd:string"/>
<xsd:element name="list" type="ldf:SimpleList"/>
<xsd:element name="formula" type="xsd:string"/>
<xsd:element ref="bgf:production"/>
<!-- later redo with MathML -->
<!--<xsd:element ref="mml:math"/>-->
</xsd:choice>
Expand Down Expand Up @@ -204,7 +205,13 @@
<xsd:sequence>
<xsd:element name="titlePage" type="ldf:titlePage"/>
<xsd:element name="placeholder" type="ldf:generated" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="frontMatter" type="ldf:frontMatter"/>
<xsd:element name="frontMatter">
<xsd:complexType>
<xsd:sequence>
<xsd:group ref="ldf:front-simple-sections" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="lists" type="ldf:frontLists" minOccurs="0"/>

<xsd:element name="lexicalPart" type="ldf:lexical" minOccurs="0"/>
Expand Down Expand Up @@ -237,116 +244,114 @@
</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="frontMatter">
<xsd:sequence>
<xsd:choice maxOccurs="unbounded">
<xsd:element name="foreword" type="ldf:SimpleSection">
<xsd:annotation>
<xsd:documentation>
Whatever the authors deem to be important enough to be put on one of the first
pages. For example, in C# specifications Foreword is about the differences brought
to the language by the current standard, while in the Scheme specification
Foreword discusses programming languages design and demonstrates its principles
applied to the forthcoming document.
</xsd:documentation>
<xsd:documentation>
Technically speaking, Foreword is not a part of the specification. Instead, it
precedes the specification and introduces it by putting in the proper context.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="designGoals" type="ldf:SimpleSection">
<xsd:annotation>
<xsd:documentation>
The goals of language design are sometimes encounted being explicitly
stated in the language document in one of the informative sections
of the front matter part.
</xsd:documentation>
<xsd:documentation>
For example:
"C# is intended to be a simple, modern, general-purpose, object-oriented
programming language."
(from ECMA 334 3rd edition, page xvii)
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="scope" type="ldf:SimpleSection">
<xsd:annotation>
<xsd:documentation>
Scope section explains the context for the language document.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="conformance" type="ldf:SimpleSection">
<xsd:annotation>
<xsd:documentation>
Conformance section defines several levels of compliance by
explaining what is a conforming program and a conforming
implementation with respect to this standard.
</xsd:documentation>
<xsd:documentation>
Definitions for meta-terms like "shall" and "should"
and their relation to the compliance issue explained above.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="compliance" type="ldf:SimpleSection">
<xsd:annotation>
<xsd:documentation>
Same as conformance
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="compatibility" type="ldf:SimpleSection">
<xsd:annotation>
<xsd:documentation>
While conformance/compliance define how external artifacts should
conform to this standard, this section defines how this standard
complies with previously existing ones.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="notation" type="ldf:SimpleSection">
<xsd:annotation>
<xsd:documentation>
Notation section defines grammar definition formalism used in the document:
mostly it is about the EBNF dialect.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="normativeReferences" type="ldf:SimpleSection">
<xsd:annotation>
<xsd:documentation>
Formally lined up references to all other standards that are used or referenced to
from within the document.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="documentStructure" type="ldf:SimpleSection">
<xsd:annotation>
<xsd:documentation>
This section informally describes how the document is organised, divided
into parts and chapters. Sometimes it explicitly states which sections are
normative and which are informative.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="whatsnew" type="ldf:SimpleSection">
<xsd:annotation>
<xsd:documentation>
A list of changes brought to the language by the current specification
replacing the previous one.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="clause" type="ldf:SimpleSection"/>
<xsd:element name="field" type="ldf:SimpleSection"/>
<!-- none of the above
<xsd:group name="front-simple-sections">
<xsd:choice>
<xsd:element name="foreword" type="ldf:SimpleSection">
<xsd:annotation>
<xsd:documentation>
Whatever the authors deem to be important enough to be put on one of the first
pages. For example, in C# specifications Foreword is about the differences brought
to the language by the current standard, while in the Scheme specification
Foreword discusses programming languages design and demonstrates its principles
applied to the forthcoming document.
</xsd:documentation>
<xsd:documentation>
Technically speaking, Foreword is not a part of the specification. Instead, it
precedes the specification and introduces it by putting in the proper context.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="designGoals" type="ldf:SimpleSection">
<xsd:annotation>
<xsd:documentation>
The goals of language design are sometimes encounted being explicitly
stated in the language document in one of the informative sections
of the front matter part.
</xsd:documentation>
<xsd:documentation>
For example:
"C# is intended to be a simple, modern, general-purpose, object-oriented
programming language."
(from ECMA 334 3rd edition, page xvii)
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="scope" type="ldf:SimpleSection">
<xsd:annotation>
<xsd:documentation>
Scope section explains the context for the language document.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="conformance" type="ldf:SimpleSection">
<xsd:annotation>
<xsd:documentation>
Conformance section defines several levels of compliance by
explaining what is a conforming program and a conforming
implementation with respect to this standard.
</xsd:documentation>
<xsd:documentation>
Definitions for meta-terms like "shall" and "should"
and their relation to the compliance issue explained above.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="compliance" type="ldf:SimpleSection">
<xsd:annotation>
<xsd:documentation>
Same as conformance
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="compatibility" type="ldf:SimpleSection">
<xsd:annotation>
<xsd:documentation>
While conformance/compliance define how external artifacts should
conform to this standard, this section defines how this standard
complies with previously existing ones.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="notation" type="ldf:SimpleSection">
<xsd:annotation>
<xsd:documentation>
Notation section defines grammar definition formalism used in the document:
mostly it is about the EBNF dialect.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="normativeReferences" type="ldf:SimpleSection">
<xsd:annotation>
<xsd:documentation>
Formally lined up references to all other standards that are used or referenced to
from within the document.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="documentStructure" type="ldf:SimpleSection">
<xsd:annotation>
<xsd:documentation>
This section informally describes how the document is organised, divided
into parts and chapters. Sometimes it explicitly states which sections are
normative and which are informative.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="whatsnew" type="ldf:SimpleSection">
<xsd:annotation>
<xsd:documentation>
A list of changes brought to the language by the current specification
replacing the previous one.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="clause" type="ldf:SimpleSection"/>
<xsd:element name="field" type="ldf:SimpleSection"/>
<!-- none of the above
<xsd:element name="core" type="ldf:SimpleSection"/>
-->
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
</xsd:choice>
</xsd:group>

<xsd:complexType name="frontLists">
<xsd:sequence minOccurs="0">
Expand Down
74 changes: 64 additions & 10 deletions shared/xsd/xbgf.xsd
Expand Up @@ -54,8 +54,22 @@
<xsd:group name="foldingtransformation">
<xsd:annotation>
<xsd:documentation>
Here is a list of the XBGF transformations that perform
folding and unfolding activities.
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 usually introduced below in
pairs.
</xsd:documentation>
</xsd:annotation>
<xsd:choice>
Expand Down Expand Up @@ -123,9 +137,33 @@
<xsd:group name="concreterevisingtransformation">
<xsd:annotation>
<xsd:documentation>
Here is a list of the XBGF transformations that
preserve abstract semantics, but do not preserve
(break) concrete semantics.
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 lenghtening nor grammar shortening transformations.
</xsd:documentation>
</xsd:annotation>
<xsd:choice>
Expand All @@ -137,8 +175,19 @@
<xsd:group name="abstractrevisingtransformation">
<xsd:annotation>
<xsd:documentation>
Here is a list of the XBGF transformations that
revise semantics, both abstract and concrete.
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 conergence
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>
Expand All @@ -153,8 +202,13 @@
<xsd:group name="decorativetransformation">
<xsd:annotation>
<xsd:documentation>
Here is a list of the XBGF transformations that perform
decorative tasks like adding or removing labels and selectors.
Last but not least, there are two pairs of 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 designate an already available production with a
label, and to unlabel an existing labelled production. By anonymising
we refer to stripping selectors from subexpressions, and by deanonymising,
naturally, adding selectors.
</xsd:documentation>
</xsd:annotation>
<xsd:choice>
Expand Down Expand Up @@ -566,7 +620,7 @@
<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.
One of them must be in a `massage relation' to the other.
</xsd:documentation>
<xsd:documentation>
The scope of
Expand Down
21 changes: 19 additions & 2 deletions shared/xsd/xldf.xsd
Expand Up @@ -37,7 +37,8 @@
<xsd:element ref="xldf:insert"/>
<xsd:element ref="xldf:move"/>
<xsd:element ref="xldf:rename"/>
<xsd:element ref="xldf:where"/>
<xsd:element ref="xldf:append"/>
<xsd:element ref="xldf:add-section"/>
</xsd:choice>
</xsd:group>

Expand Down Expand Up @@ -66,6 +67,22 @@
</xsd:complexType>
</xsd:element>

<xsd:element name="add-section">
<xsd:annotation>
<xsd:documentation>
TBD
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:choice>
<xsd:element name="front" type="ldf:frontMatter"/>
<xsd:element name="list" type="ldf:frontLists"/>
<xsd:element name="lexical" type="ldf:lexical"/>
<xsd:element name="core" type="ldf:StructuredSection"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>

<xsd:element name="move">
<xsd:annotation>
<xsd:documentation>
Expand All @@ -75,7 +92,7 @@
<xsd:complexType>
<xsd:sequence>
<xsd:element name="section" type="xsd:string"/> <!-- IDREF -->
<xsd:element name="inside" type="xsd:string"/> <!-- IDREF -->
<xsd:element name="inside" type="xsd:string"/> <!-- IDREF -->
</xsd:sequence>
</xsd:complexType>
</xsd:element>
Expand Down

0 comments on commit 22e4839

Please sign in to comment.