From 8f5ff87a8c11dedbeb5179fb36a783127d545459 Mon Sep 17 00:00:00 2001 From: grammarware Date: Wed, 25 Feb 2009 23:08:43 +0000 Subject: [PATCH] xldf:move is not xldf:place; xbgf.bgf completion split into several files git-svn-id: https://slps.svn.sourceforge.net/svnroot/slps@496 ab42f6e0-554d-0410-b580-99e487e6eeb2 --- shared/xsd/ldf.xsd | 1 + shared/xsd/xldf.xsd | 29 +- topics/languedoc/Makefile | 54 ++- topics/languedoc/bnf/xbgf/preferBnf.xbgf | 26 +- topics/languedoc/complete.xldf | 391 ------------------ topics/languedoc/xldf/completeDecSection.xldf | 31 ++ .../languedoc/xldf/completeDecorSection.xldf | 31 ++ .../languedoc/xldf/completeFoldSection.xldf | 112 +++++ topics/languedoc/xldf/completeIncSection.xldf | 35 ++ topics/languedoc/xldf/completeIntro.xldf | 199 +++++++++ topics/languedoc/xldf/completeRefSection.xldf | 103 +++++ .../languedoc/xldf/completeRevSections.xldf | 59 +++ topics/transformation/xldf/xldf.py | 63 ++- 13 files changed, 690 insertions(+), 444 deletions(-) delete mode 100644 topics/languedoc/complete.xldf create mode 100644 topics/languedoc/xldf/completeDecSection.xldf create mode 100644 topics/languedoc/xldf/completeDecorSection.xldf create mode 100644 topics/languedoc/xldf/completeFoldSection.xldf create mode 100644 topics/languedoc/xldf/completeIncSection.xldf create mode 100644 topics/languedoc/xldf/completeIntro.xldf create mode 100644 topics/languedoc/xldf/completeRefSection.xldf create mode 100644 topics/languedoc/xldf/completeRevSections.xldf diff --git a/shared/xsd/ldf.xsd b/shared/xsd/ldf.xsd index 15e82dfb..4cb24259 100644 --- a/shared/xsd/ldf.xsd +++ b/shared/xsd/ldf.xsd @@ -57,6 +57,7 @@ + diff --git a/shared/xsd/xldf.xsd b/shared/xsd/xldf.xsd index 42efc693..888d9f32 100644 --- a/shared/xsd/xldf.xsd +++ b/shared/xsd/xldf.xsd @@ -35,8 +35,9 @@ - - + + + @@ -84,7 +85,7 @@ - + TBD @@ -133,16 +134,30 @@ - + - Deprecated + TBD + + + + + + + + + + + + + + TBD - - + + diff --git a/topics/languedoc/Makefile b/topics/languedoc/Makefile index 1b54bc07..46bf7329 100644 --- a/topics/languedoc/Makefile +++ b/topics/languedoc/Makefile @@ -1,32 +1,44 @@ -build: - ../../shared/tools/xsd2bgf ../../shared/xsd/ldf.xsd ldf.bgf - ../../topics/extraction/xsd2ldf/ldfgen.py ../../shared/xsd/ldf.xsd ldf.bgf ldf.ldf - ../../shared/tools/ldf2pdf ldf.ldf ldf.pdf +validator = ../../shared/tools/checkxml -test: +build: bgf_pretty.bgf xbgf.ldf + python ../../topics/transformation/xldf/xldf.py xldf/completeIntro.xldf xbgf.ldf xbgf1.ldf + python ../../topics/transformation/xldf/xldf.py xldf/completeFoldSection.xldf xbgf1.ldf xbgf2.ldf + python ../../topics/transformation/xldf/xldf.py xldf/completeRefSection.xldf xbgf2.ldf xbgf3.ldf + python ../../topics/transformation/xldf/xldf.py xldf/completeIncSection.xldf xbgf3.ldf xbgf4.ldf + python ../../topics/transformation/xldf/xldf.py xldf/completeDecSection.xldf xbgf4.ldf xbgf5.ldf + python ../../topics/transformation/xldf/xldf.py xldf/completeRevSections.xldf xbgf5.ldf xbgf6.ldf + python ../../topics/transformation/xldf/xldf.py xldf/completeDecorSection.xldf xbgf6.ldf xbgf7.ldf + xsltproc ../../shared/xsl/ldf2tex.xslt xbgf7.ldf > xbgf.tex + pdflatex -interaction=batchmode xbgf + pdflatex -interaction=batchmode xbgf -xbgf: - ../../shared/tools/xsd2bgf ../../shared/xsd/xbgf.xsd xbgf.bgf - ../../shared/tools/xbgf beautify.xbgf xbgf.bgf xbgf_1.bgf - ../../topics/extraction/xsd2ldf/ldfgen.py ../../shared/xsd/xbgf.xsd xbgf_1.bgf xbgf.ldf - python ../../topics/transformation/xldf/xldf.py complete.xldf xbgf.ldf xbgf_1.ldf - xsltproc ../../shared/xsl/ldf2xhtml.xslt xbgf_1.ldf | python ../../topics/presentation/ldf2pdf/closemeta.py > xbgf.html - xsltproc ../../shared/xsl/xhtml2fo.xslt xbgf.html > xbgf.fo - ../../download/fop/fop -q xbgf.fo xbgf.pdf +bgf_pretty.bgf: + ../../shared/tools/xsd2bgf ../../shared/xsd/bgf.xsd bgf.bgf + ../../shared/tools/xbgf beautify_bgf.xbgf bgf.bgf bgf_pretty.bgf -tex: +xbgf.ldf: ../../shared/tools/xsd2bgf ../../shared/xsd/xbgf.xsd xbgf.bgf - ../../shared/tools/xsd2bgf ../../shared/xsd/bgf.xsd bgf.bgf ../../shared/tools/xbgf beautify_xbgf.xbgf xbgf.bgf xbgf_1.bgf - ../../shared/tools/xbgf beautify_bgf.xbgf bgf.bgf bgf_pretty.bgf ../../topics/extraction/xsd2ldf/ldfgen.py ../../shared/xsd/xbgf.xsd xbgf_1.bgf xbgf.ldf - python ../../topics/transformation/xldf/xldf.py complete.xldf xbgf.ldf xbgf_1.ldf - xsltproc ../../shared/xsl/ldf2tex.xslt xbgf_1.ldf > xbgf.tex - pdflatex -interaction=batchmode xbgf - pdflatex -interaction=batchmode xbgf + +rebuild: + make clean + make samples + make build + +samples: + ../../shared/tools/xbgf2xbnf bnf/xbgf/designate.xbgf designate.xbnf + ../../shared/tools/xbgf2xbnf bnf/xbgf/preferBnf.xbgf preferBnf.xbnf + ../../shared/tools/xbgf2xbnf bnf/xbgf/refactorBnf.xbgf refactorBnf.xbnf + ../../shared/tools/xbgf2xbnf bnf/xbgf/stripTerminals.xbgf stripTerminals.xbnf + ../../shared/tools/xbgf2xbnf bnf/xbgf/stripWhitespace.xbgf stripWhitespace.xbnf clean: - rm -f xbgf*.bgf xbgf*.ldf xbgf.html xbgf.fo xbgf.pdf + rm -f xbgf*.bgf xbgf*.ldf xbgf.html xbgf.fo xbgf.pdf *.xbnf rm -f bgf*.bgf ldf*.bgf ldf*.ldf ldf.fo ldf.pdf rm -f *.aux *.log *.toc *.tex +check: + ls -1 *.xbgf | xargs -n1 ${validator} xbgf + ls -1 *.bgf | xargs -n1 ${validator} bgf + ls -1 *.ldf | xargs -n1 ${validator} ldf diff --git a/topics/languedoc/bnf/xbgf/preferBnf.xbgf b/topics/languedoc/bnf/xbgf/preferBnf.xbgf index 132d4a68..9e42c00b 100644 --- a/topics/languedoc/bnf/xbgf/preferBnf.xbgf +++ b/topics/languedoc/bnf/xbgf/preferBnf.xbgf @@ -35,16 +35,8 @@ - - - expression - symbol - - - label - terminal - nonterminal - selector + + @@ -62,6 +54,17 @@ + + + expression + symbol + + + label + terminal + nonterminal + selector + symbol @@ -69,5 +72,4 @@ value - - \ No newline at end of file + diff --git a/topics/languedoc/complete.xldf b/topics/languedoc/complete.xldf deleted file mode 100644 index d75b3c9c..00000000 --- a/topics/languedoc/complete.xldf +++ /dev/null @@ -1,391 +0,0 @@ - - - - - - Vadim Zaytsev - -

- XBGF operator suite was developed mainly for grammar convergence - activities. -

- - - - - - - notation-section - Vadim Zaytsev - -

- BGF is a BNF-like Grammar Format, an XML dialect of Extended Backus Naur Form - that was used in the language convergence infrastructure. -

- - - - - - notation-section - bgf_pretty.bgf - - - - notation-section - -

- All BGFs and XBGFs are presented in a unified pretty-printed way. - The concrete syntax for it is presented below: -

- - - - - notation-section - bnf.bgf - - - - -

- 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. -

- - -

The massage relation is defined as follows:

- (x^+)? = x^\star - (x^\star)? = x^\star - (x?)? = x? - (x^\star)^\star = x^\star - (x^+)^\star = x^\star - (x?)^\star = x^\star - (x^+)^+ = x^+ - (x^\star)^+ = x^\star - (x?)^+ = x^\star -

The following formulae are more complicated examples of masssage:

- x|\varepsilon = x? - x|x = x - x^+|\varepsilon = x^\star - x^+|x? = x^\star - x x^\star = x^+ - x (yx)^\star = (xy)^\star x - x (yx)^+ = (xy)^+ x -

Another rule that is harder to express is when

- x? = x -

in the cases when x is optional anyway, i.e. it is one of the following:

- \varepsilon|... - y? - y^\star - y|... - y z ... -

where y and z are also recursively optional anyway.

- - - - - - - foldingtransformation - - Folding and unfolding transformations - - -
element-unfold
- group-foldingtransformation - - - -

- The definition that is being unfolded is assumed to be horisontal - (see the section on refactorings for more information about horisontal - and vertical definitions). -

- - -

- Almost all the unfold transformations used in Java Language Specification - case are restricted in scope by a nonterminal. The reason for such statistics - is that when the language engineer wants to give up the nonterminal, he uses - the inline transformations. On the other hand, unfold usually happens as a - part of sequences with fold, downgrade, disappear, deyaccify, distribute, - etc.---in which case it is only natural to try to limit the impact of every - step. -

- - - -
element-fold
- group-foldingtransformation - - -
element-inline
- group-foldingtransformation - - - element-inline - -

- The inline transformation is by far the most used in Java Language Specification - case. One of the reasons is what we call layering: in particular expressions - and statements are introduced in the $G_j^R$ with a set of related nonterminals: - LabeledStatement, IfThenElseStatement, WhileStatement, ForStatement, etc, and - CastExpression, PreIncrementExpression, PreDecrementExpression, PostfixExpression, etc. - $G_j^I$ takes another approach, just listing all the alternatives in the productions - for Statement and Expression. In order to converge these two variants, a lot of inline - transformations are needed. This can also be apparent from the statistics table, - that demonstrates that targets that converge only `readable' grammars require up to - ten inline transformations each, while each target that takes both readable and - implementable grammars in, contains 70--100 inline transformations in convergence path. -

- - - -
element-extract
- group-foldingtransformation - - - element-extract - -

- As seen from the experience gained from Java Language Specification case, - it is highly unusual for extract to have limited scope. However, sometimes - a limited impact is desired in order to avoid excessive subsequent unfoldings - when the convergence requests for having several nonterminals with similar - definitions. -

- - - -
element-abridge
- group-foldingtransformation - - - element-abridge - -

- Reflexive chain productions are rarely encountered explicitly, so it calls for more clear explanation. - However, after a series of transformations one can arrive at the point of having such - a production and, quite naturally, wanting to get rid of it. An example of a transformation - sequence that yields a reflexive chain production can be a step from concrete syntax definition - to abstract syntax definition. Concrete syntax usually needs explicit bracketing constructions for - recursive composition, and after stripping away terminals and merging layers, these bracketing - constructions become reflexive chain productions. The Factorial Language case has shown the need - for it. -

- - - -
element-detour
- group-foldingtransformation - - -
element-unchain
- group-foldingtransformation - - -
element-chain
- group-foldingtransformation - - - - - - refactoringtransformation - - Other refactoring transformations - - -
element-massage
- group-refactoringtransformation - - -
element-factor
- group-refactoringtransformation - - -
element-distribute
- group-refactoringtransformation - - -
element-deyaccify
- group-refactoringtransformation - - -
element-yaccify
- group-refactoringtransformation - - -
element-eliminate
- group-refactoringtransformation - - -
element-introduce
- group-refactoringtransformation - - -
element-import
- group-refactoringtransformation - - -
element-vertical
- group-refactoringtransformation - - -
element-horizontal
- group-refactoringtransformation - - -
element-rassoc
- group-refactoringtransformation - - -
element-lassoc
- group-refactoringtransformation - - - - - - increasingtransformation - - Grammar lengthening transformations - - -
element-add
- group-increasingtransformation - - -
element-appear
- group-increasingtransformation - - -
element-widen
- group-increasingtransformation - - -
element-upgrade
- group-increasingtransformation - - -
element-unite
- group-increasingtransformation - - - - - - decreasingtransformation - - Grammar shortening transformations - - -
element-remove
- group-decreasingtransformation - - -
element-disappear
- group-decreasingtransformation - - -
element-narrow
- group-decreasingtransformation - - -
element-downgrade
- group-decreasingtransformation - - - - - - concreterevisingtransformation - - Refactorings in term-oriented semantics - - -
element-abstractize
- group-concreterevisingtransformation - - -
element-concretize
- group-concreterevisingtransformation - - -
element-permute
- group-concreterevisingtransformation - - - - - - abstractrevisingtransformation - - Semantics revising transformations - - -
element-define
- group-abstractrevisingtransformation - - -
element-undefine
- group-abstractrevisingtransformation - - -
element-redefine
- group-abstractrevisingtransformation - - -
element-inject
- group-abstractrevisingtransformation - - -
element-project
- group-abstractrevisingtransformation - - -
element-replace
- group-abstractrevisingtransformation - - - - - - decorativetransformation - - Decorative transformations - - -
element-designate
- group-decorativetransformation - - -
element-unlabel
- group-decorativetransformation - - -
element-anonymize
- group-decorativetransformation - - -
element-deanonymize
- group-decorativetransformation - - - - - \ No newline at end of file diff --git a/topics/languedoc/xldf/completeDecSection.xldf b/topics/languedoc/xldf/completeDecSection.xldf new file mode 100644 index 00000000..062bb650 --- /dev/null +++ b/topics/languedoc/xldf/completeDecSection.xldf @@ -0,0 +1,31 @@ + + + + + + + decreasingtransformation + + Grammar shortening transformations + + +
element-remove
+ group-decreasingtransformation + + +
element-disappear
+ group-decreasingtransformation + + +
element-narrow
+ group-decreasingtransformation + + +
element-downgrade
+ group-decreasingtransformation + + + \ No newline at end of file diff --git a/topics/languedoc/xldf/completeDecorSection.xldf b/topics/languedoc/xldf/completeDecorSection.xldf new file mode 100644 index 00000000..1ca1f66e --- /dev/null +++ b/topics/languedoc/xldf/completeDecorSection.xldf @@ -0,0 +1,31 @@ + + + + + + + decorativetransformation + + Decorative transformations + + +
element-designate
+ group-decorativetransformation + + +
element-unlabel
+ group-decorativetransformation + + +
element-anonymize
+ group-decorativetransformation + + +
element-deanonymize
+ group-decorativetransformation + + + \ No newline at end of file diff --git a/topics/languedoc/xldf/completeFoldSection.xldf b/topics/languedoc/xldf/completeFoldSection.xldf new file mode 100644 index 00000000..acf9882b --- /dev/null +++ b/topics/languedoc/xldf/completeFoldSection.xldf @@ -0,0 +1,112 @@ + + + + + + + foldingtransformation + + Folding and unfolding transformations + + +
element-unfold
+ group-foldingtransformation + + + +

+ The definition that is being unfolded is assumed to be horisontal + (see the section on refactorings for more information about horisontal + and vertical definitions). +

+ + +

+ Almost all the unfold transformations used in Java Language Specification + case are restricted in scope by a nonterminal. The reason for such statistics + is that when the language engineer wants to give up the nonterminal, he uses + the inline transformations. On the other hand, unfold usually happens as a + part of sequences with fold, downgrade, disappear, deyaccify, distribute, + etc.---in which case it is only natural to try to limit the impact of every + step. +

+ + + +
element-fold
+ group-foldingtransformation + + +
element-inline
+ group-foldingtransformation + + + element-inline + +

+ The inline transformation is by far the most used in Java Language Specification + case. One of the reasons is what we call layering: in particular expressions + and statements are introduced in the $G_j^R$ with a set of related nonterminals: + LabeledStatement, IfThenElseStatement, WhileStatement, ForStatement, etc, and + CastExpression, PreIncrementExpression, PreDecrementExpression, PostfixExpression, etc. + $G_j^I$ takes another approach, just listing all the alternatives in the productions + for Statement and Expression. In order to converge these two variants, a lot of inline + transformations are needed. This can also be apparent from the statistics table, + that demonstrates that targets that converge only `readable' grammars require up to + ten inline transformations each, while each target that takes both readable and + implementable grammars in, contains 70--100 inline transformations in convergence path. +

+ + + +
element-extract
+ group-foldingtransformation + + + element-extract + +

+ As seen from the experience gained from Java Language Specification case, + it is highly unusual for extract to have limited scope. However, sometimes + a limited impact is desired in order to avoid excessive subsequent unfoldings + when the convergence requests for having several nonterminals with similar + definitions. +

+ + + +
element-abridge
+ group-foldingtransformation + + + element-abridge + +

+ Reflexive chain productions are rarely encountered explicitly, so it calls for more clear explanation. + However, after a series of transformations one can arrive at the point of having such + a production and, quite naturally, wanting to get rid of it. An example of a transformation + sequence that yields a reflexive chain production can be a step from concrete syntax definition + to abstract syntax definition. Concrete syntax usually needs explicit bracketing constructions for + recursive composition, and after stripping away terminals and merging layers, these bracketing + constructions become reflexive chain productions. The Factorial Language case has shown the need + for it. +

+ + + +
element-detour
+ group-foldingtransformation + + +
element-unchain
+ group-foldingtransformation + + +
element-chain
+ group-foldingtransformation + + + \ No newline at end of file diff --git a/topics/languedoc/xldf/completeIncSection.xldf b/topics/languedoc/xldf/completeIncSection.xldf new file mode 100644 index 00000000..d999d4d9 --- /dev/null +++ b/topics/languedoc/xldf/completeIncSection.xldf @@ -0,0 +1,35 @@ + + + + + + + increasingtransformation + + Grammar lengthening transformations + + +
element-add
+ group-increasingtransformation + + +
element-appear
+ group-increasingtransformation + + +
element-widen
+ group-increasingtransformation + + +
element-upgrade
+ group-increasingtransformation + + +
element-unite
+ group-increasingtransformation + + + \ No newline at end of file diff --git a/topics/languedoc/xldf/completeIntro.xldf b/topics/languedoc/xldf/completeIntro.xldf new file mode 100644 index 00000000..e9d3927e --- /dev/null +++ b/topics/languedoc/xldf/completeIntro.xldf @@ -0,0 +1,199 @@ + + + + + + Vadim Zaytsev + +

+ XBGF operator suite was developed mainly for grammar convergence + activities. +

+ + + + + + + notation-section + Vadim Zaytsev + +

+ BGF is a BNF-like Grammar Format, an XML dialect of Extended Backus Naur Form + that was used in the language convergence infrastructure. Its grammar is presented + below in a slightly beautified form (all undefined nonterminals are strings): +

+ + + + + + notation-section + bgf_pretty.bgf + + + + notation-section + +

+ All BGFs and XBGFs are presented in a unified pretty-printed way. + The concrete syntax for it is presented below: +

+ + + + + notation-section + bnf.bgf + + + + + + compatibility-section + Vadim Zaytsev + +

+ In order to establish the relation between BGF that is being used + in the actual working system and BNF that is being reported here, + we apply the whole process of grammar convergence to these two grammars. +

+

+ BNF was defined as a base-line grammar for a pretty-printer and therefor + defines concrete syntax. BGF is extracted from the corresponding XML Schema + and contains abstract syntax annotated with selectors. We choose to converge + them closer to abstract syntax (BGF). The only transformations applied to + the BGF grammar are these: +

+ + + + + + compatibility-section + preferBnf.xbnf + + + + compatibility-section + +

+ As we can see, the first two transformations resolve the issue of + BGF having a notion of `root element' and BNF not having such a notion + at all. The third transformation, narrow, shortens the grammar, but + its semantics only means that we do not want to have empty samples + while an empty grammar is still acceptable in general. Since this is + data refinement, a semantic decreasing transformation is used without + hesitation. The rest of the transformational sequence is trivial refactorings. +

+

+ The BNF source undergoes the following transformations for stripping + it from lexical details: +

+ + + + + compatibility-section + stripWhitespace.xbnf + + + + compatibility-section + +

+ Before the rest of the concrete syntax (i.e., the terminals) + is stripped away, we need to add some labels that correspond + to the selectors of its BGF counterpart: +

+ + + + + compatibility-section + designate.xbnf + + + + compatibility-section + +

+ Now we can remove all terminals from the grammar without disrupting + its structure (i.e., various alternatives in symbol will not collide + and vanish during normalisation phase). Since we do not want to make + a distinction and deem all terminals to be worthy of removal, the + following transformation script is generated by a special tool executed + automatically from LCI. +

+ + + + + compatibility-section + stripTerminals.xbnf + + + + compatibility-section + +

+ Finally we run a grammar comparator to see what is left and notice + one mismatch that is easily fixed with massage, as well as the right + hand side still having $(symbol^+)^+$ instead of just symbol. This + corresponds to the design decision that treats top-level choices + and top-level sequences differently in BNF to make them more appealing + to the eye by avoiding unnecessary parenthesizing. The very specific + upgrade command is run twice here to fold first the sequence and then + the choice. After that, the grammars fully converge. +

+ + + + + compatibility-section + refactorBnf.xbnf + + + + + + definitions-section + Vadim Zaytsev + + grammar + +

A set of interdependent productions.

+ + + + + + +
element-sequence
+ definitions-section + + + +
group-transformation
+ definitions-section + + + +
group-scope
+ definitions-section + + + + \ No newline at end of file diff --git a/topics/languedoc/xldf/completeRefSection.xldf b/topics/languedoc/xldf/completeRefSection.xldf new file mode 100644 index 00000000..67d1f7f0 --- /dev/null +++ b/topics/languedoc/xldf/completeRefSection.xldf @@ -0,0 +1,103 @@ + + + + + + + refactoringtransformation + + Other refactoring transformations + + +
element-massage
+ group-refactoringtransformation + + + + +

+ 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. +

+ + +

The massage relation is defined as follows:

+ (x^+)? = x^\star + (x^\star)? = x^\star + (x?)? = x? + (x^\star)^\star = x^\star + (x^+)^\star = x^\star + (x?)^\star = x^\star + (x^+)^+ = x^+ + (x^\star)^+ = x^\star + (x?)^+ = x^\star +

The following formulae are more complicated examples of masssage:

+ x|\varepsilon = x? + x|x = x + x^+|\varepsilon = x^\star + x^+|x? = x^\star + x x^\star = x^+ + x (yx)^\star = (xy)^\star x + x (yx)^+ = (xy)^+ x +

Another rule that is harder to express is when

+ x? = x +

in the cases when x is optional anyway, i.e. it is one of the following:

+ \varepsilon|... + y? + y^\star + y|... + y z ... +

where y and z are also recursively optional anyway.

+ + + + +
element-factor
+ group-refactoringtransformation + + +
element-distribute
+ group-refactoringtransformation + + +
element-deyaccify
+ group-refactoringtransformation + + +
element-yaccify
+ group-refactoringtransformation + + +
element-eliminate
+ group-refactoringtransformation + + +
element-introduce
+ group-refactoringtransformation + + +
element-import
+ group-refactoringtransformation + + +
element-vertical
+ group-refactoringtransformation + + +
element-horizontal
+ group-refactoringtransformation + + +
element-rassoc
+ group-refactoringtransformation + + +
element-lassoc
+ group-refactoringtransformation + + + \ No newline at end of file diff --git a/topics/languedoc/xldf/completeRevSections.xldf b/topics/languedoc/xldf/completeRevSections.xldf new file mode 100644 index 00000000..f20eceb1 --- /dev/null +++ b/topics/languedoc/xldf/completeRevSections.xldf @@ -0,0 +1,59 @@ + + + + + + + concreterevisingtransformation + + Refactorings in term-oriented semantics + + +
element-abstractize
+ group-concreterevisingtransformation + + +
element-concretize
+ group-concreterevisingtransformation + + +
element-permute
+ group-concreterevisingtransformation + + + + + + abstractrevisingtransformation + + Semantics revising transformations + + +
element-define
+ group-abstractrevisingtransformation + + +
element-undefine
+ group-abstractrevisingtransformation + + +
element-redefine
+ group-abstractrevisingtransformation + + +
element-inject
+ group-abstractrevisingtransformation + + +
element-project
+ group-abstractrevisingtransformation + + +
element-replace
+ group-abstractrevisingtransformation + + + \ No newline at end of file diff --git a/topics/transformation/xldf/xldf.py b/topics/transformation/xldf/xldf.py index 45c14575..a56f0a7c 100755 --- a/topics/transformation/xldf/xldf.py +++ b/topics/transformation/xldf/xldf.py @@ -93,21 +93,33 @@ def xldf_append(cmd,tree): print ')' return -def xldf_move(cmd,tree): +def xldf_place(cmd,tree): #found = tree.findall('//core[id="'+cmd.findtext('./section')+'"]') found = findnode(tree,cmd.findtext('section')) if not found: - print '[----] xldf:move failed: source node not found!' + print '[----] xldf:place failed: source node not found!' return #found2 = tree.findall('//core[id="'+cmd.findtext('./inside')+'"]') found2 = findnode(tree,cmd.findtext('inside')) if not found2: - print '[----] xldf:move failed: target node not found!' + print '[----] xldf:place failed: target node not found!' return - found.tag = 'subtopic' - found2.append(found) - tree.getroot().remove(found) - print '[XLDF] move('+cmd.findtext('section')+',',cmd.findtext('inside')+')' + if found2.tag=='core': + found.tag = 'subtopic' + found2.append(found) + tree.getroot().remove(found) + print '[XLDF] place('+cmd.findtext('section')+',',cmd.findtext('inside')+')' + elif found2.tag in ('definitions','abbreviations','languageOverview'): + el = ET.SubElement(found2,'term') + el2 = ET.SubElement(el,'name') + el2.text = found.findtext('title') + el2 = ET.SubElement(el,'definition') + for el in found.findall('.//content/*'): + el2.append(el) + tree.getroot().remove(found) + print '[XLDF] place('+cmd.findtext('section')+',',cmd.findtext('inside')+')' + else: + print '[----] xldf:place failed: don''t know how to place subsections in',found2.tag return def xldf_rename(cmd,tree): @@ -144,7 +156,14 @@ def xldf_add_section(cmd,tree): print '[XLDF] add-section to front matter' success = True elif s.tag in ('definitions','abbreviations','languageOverview'): - tree.findall('//lists')[0].append(s) + if tree.findall('//lists'): + tree.findall('//lists')[0].append(s) + else: + el = ET.Element('lists',{}) + el.append(s) + for i in range(0,len(tree.findall('*'))): + if tree.getroot()[i].tag=='frontMatter': + tree.getroot().insert(i+1,el) print '[XLDF] add-section to lists' success = True elif s.tag in ('lineContinuations','whitespace','tokens','preprocessor','literals','lexical'): @@ -159,7 +178,7 @@ def xldf_add_section(cmd,tree): print '[----] add-section failed' return -def xldf_import(cmd,tree): +def xldf_import_grammar(cmd,tree): try: gtree = ET.parse(cmd.findtext('file')) except IOError,e: @@ -179,6 +198,22 @@ def xldf_import(cmd,tree): print '[----] xldf:import failed: no productions found in',cmd.findtext('file') return +def xldf_import_sample(cmd,tree): + try: + sample = open(cmd.findtext('file'),'r') + except IOError,e: + print '[----] xldf:import failed: file',cmd.findtext('file'),'not found' + return + found = findnode(tree,cmd.findtext('target')) + if not found: + print '[----] xldf:import failed: target id',cmd.findtext('where'),'not found' + else: + el = ET.Element('sample',{}) + el.text = ''.join(sample.readlines()) + found[-1].append(el) + print '[XLDF] import(',cmd.findtext('target'),',',cmd.findtext('file'),')' + return + def main(xldffile,inldffile,outldffile): grammar={} xtree = ET.parse(xldffile) @@ -188,10 +223,12 @@ def main(xldffile,inldffile,outldffile): cmdname = cmd.tag.replace('{'+xldfns+'}','') if cmdname == 'insert': xldf_insert(cmd,ltree) - elif cmdname == 'import': - xldf_import(cmd,ltree) - elif cmdname == 'move': - xldf_move(cmd,ltree) + elif cmdname == 'import-grammar': + xldf_import_grammar(cmd,ltree) + elif cmdname == 'import-sample': + xldf_import_sample(cmd,ltree) + elif cmdname == 'place': + xldf_place(cmd,ltree) elif cmdname == 'rename': xldf_rename(cmd,ltree) elif cmdname == 'append':