processing the processing model
The next step in getting procmod into the Guidelines ought to be to produce some test files. However, as James mentioned earlier, this is not entirely straightforward. I can dream up sample ODDs which include <model> elements no problem, and can then validate them against the schemas generated from the current source. I can also re-use the ones in the Polygon directory in the original tei-simple repo, written by Magdalena. (why is it called "Polygon" btw?) However, should we not also be producing a test implementation or two showing the actual output generated with the aid of those models? That would require adding, presumably into the Stylesheets tree, some version of Magda's pilot version of a stylesheet for transforming <model>s into XSL. Or is that already there somewhere? Or are we just planning to keep quiet about the whole thing?
Hi, as for test files, I guess we should test roughly three classes of things 1. as you pointed out, that sample ODDs including <model> elements do validate against TEI schemas 2. sample TEI Simple files can be converted into output using processing model and this output is as expected (test files for this are in https://github.com/TEIC/TEI-Simple/tree/master/tests, let me clear them up a bit and provide you with magic commands for executing the tests) 3. tests that sample ODDs get converted into expected XSLTs/XQueries by processing model 2 is already in place, or almost, 1 most probably straightforward for Lou or James and I guess even I could do it if I had an afternoon to kill. We have nothing for 3 as yet, though what we could easily do is take the ODD we have and results of application of current processing model implementations as our expected output. To satiate your curiosity: "poligon" in Polish means military training area, where you can shoot and run soldiers around without causing collateral damage. The closest English word (in looks, not meaning, though I believe the roots of the Polish and English words are indeed the same) is polygon, so that's how it got to be named like that. Sorry if it tells too much about my mental processes. I am trying to keep afloat and not to sink under pressing work obligations, but if I took to it early next week would that be acceptable for you? Magdalena On 28 January 2016 at 10:22, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
The next step in getting procmod into the Guidelines ought to be to produce some test files. However, as James mentioned earlier, this is not entirely straightforward.
I can dream up sample ODDs which include <model> elements no problem, and can then validate them against the schemas generated from the current source. I can also re-use the ones in the Polygon directory in the original tei-simple repo, written by Magdalena. (why is it called "Polygon" btw?)
However, should we not also be producing a test implementation or two showing the actual output generated with the aid of those models? That would require adding, presumably into the Stylesheets tree, some version of Magda's pilot version of a stylesheet for transforming <model>s into XSL. Or is that already there somewhere?
Or are we just planning to keep quiet about the whole thing?
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
Hi Magda OK I will carry on producing some simple test files for (1). On (2) I'm not sure why you mention sample Simple files here: I think that's a separate exercise. Obviously we will need to revisit them when we start work on the TEI Simple Exemplar: but you shouldn't let that stop you working your magic! How exactly do we do number 3? You havent answered my question about the Stylesheet implications: is there somewhere a fragment of XSLT which knows about the proposed "behaviours" which we can integrate into the Stylesheet library? And thanks for explaining the poligon! L On 28/01/16 10:48, Magdalena Turska wrote:
Hi,
as for test files, I guess we should test roughly three classes of things 1. as you pointed out, that sample ODDs including <model> elements do validate against TEI schemas 2. sample TEI Simple files can be converted into output using processing model and this output is as expected (test files for this are in https://github.com/TEIC/TEI-Simple/tree/master/tests, let me clear them up a bit and provide you with magic commands for executing the tests) 3. tests that sample ODDs get converted into expected XSLTs/XQueries by processing model
2 is already in place, or almost, 1 most probably straightforward for Lou or James and I guess even I could do it if I had an afternoon to kill. We have nothing for 3 as yet, though what we could easily do is take the ODD we have and results of application of current processing model implementations as our expected output.
To satiate your curiosity: "poligon" in Polish means military training area, where you can shoot and run soldiers around without causing collateral damage. The closest English word (in looks, not meaning, though I believe the roots of the Polish and English words are indeed the same) is polygon, so that's how it got to be named like that. Sorry if it tells too much about my mental processes.
I am trying to keep afloat and not to sink under pressing work obligations, but if I took to it early next week would that be acceptable for you?
Magdalena
On 28 January 2016 at 10:22, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
The next step in getting procmod into the Guidelines ought to be to produce some test files. However, as James mentioned earlier, this is not entirely straightforward.
I can dream up sample ODDs which include <model> elements no problem, and can then validate them against the schemas generated from the current source. I can also re-use the ones in the Polygon directory in the original tei-simple repo, written by Magdalena. (why is it called "Polygon" btw?)
However, should we not also be producing a test implementation or two showing the actual output generated with the aid of those models? That would require adding, presumably into the Stylesheets tree, some version of Magda's pilot version of a stylesheet for transforming <model>s into XSL. Or is that already there somewhere?
Or are we just planning to keep quiet about the whole thing?
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
Poligon is no longer relevant, as I did reorganize the repo a bit, so procmod xslts ended up here https://github.com/TEIC/TEI-Simple/tree/master/processingModel The simplest way to use xslt version is to take your ODD and run simpleoddtoxsl.xsl on in saxon -xi -s:my.odd -o:simple.xsl -xsl:simpleoddtoxsl.xsl Which should generate a stylesheet that one could use for transformation of tei files. The fragments that 'knows about behaviours' are https://github.com/TEIC/TEI-Simple/blob/master/processingModel/html_function... (for transforms into html) and latex_functions.xsl (dunno how complete this one is). So these files are where the behaviours definitions live, while actual magic that controls the whole process happens in polygon_lib.xsl Therefore the easiest way to do the tests of type 3. would be to take current teisimple.odd, generate output xsl as shown above and store it as expected result. M On 28 January 2016 at 11:42, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
Hi Magda
OK I will carry on producing some simple test files for (1).
On (2) I'm not sure why you mention sample Simple files here: I think that's a separate exercise. Obviously we will need to revisit them when we start work on the TEI Simple Exemplar: but you shouldn't let that stop you working your magic!
How exactly do we do number 3? You havent answered my question about the Stylesheet implications: is there somewhere a fragment of XSLT which knows about the proposed "behaviours" which we can integrate into the Stylesheet library?
And thanks for explaining the poligon!
L
On 28/01/16 10:48, Magdalena Turska wrote:
Hi,
as for test files, I guess we should test roughly three classes of things 1. as you pointed out, that sample ODDs including <model> elements do validate against TEI schemas 2. sample TEI Simple files can be converted into output using processing model and this output is as expected (test files for this are in https://github.com/TEIC/TEI-Simple/tree/master/tests, let me clear them up a bit and provide you with magic commands for executing the tests) 3. tests that sample ODDs get converted into expected XSLTs/XQueries by processing model
2 is already in place, or almost, 1 most probably straightforward for Lou or James and I guess even I could do it if I had an afternoon to kill. We have nothing for 3 as yet, though what we could easily do is take the ODD we have and results of application of current processing model implementations as our expected output.
To satiate your curiosity: "poligon" in Polish means military training area, where you can shoot and run soldiers around without causing collateral damage. The closest English word (in looks, not meaning, though I believe the roots of the Polish and English words are indeed the same) is polygon, so that's how it got to be named like that. Sorry if it tells too much about my mental processes.
I am trying to keep afloat and not to sink under pressing work obligations, but if I took to it early next week would that be acceptable for you?
Magdalena
On 28 January 2016 at 10:22, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
The next step in getting procmod into the Guidelines ought to be to
produce some test files. However, as James mentioned earlier, this is not entirely straightforward.
I can dream up sample ODDs which include <model> elements no problem, and can then validate them against the schemas generated from the current source. I can also re-use the ones in the Polygon directory in the original tei-simple repo, written by Magdalena. (why is it called "Polygon" btw?)
However, should we not also be producing a test implementation or two showing the actual output generated with the aid of those models? That would require adding, presumably into the Stylesheets tree, some version of Magda's pilot version of a stylesheet for transforming <model>s into XSL. Or is that already there somewhere?
Or are we just planning to keep quiet about the whole thing?
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
Thanks, that clarifies my question below. There is quite a big policy decision here though. Do we want to disentangle the processing model processing tools from simple and integrate them properly into the existing stylesheets library? If we do, that's work we ought to do in tandem with defining the proc mod spec in the Guidelines. If we don't then the proc mod spec ought simply to say that an experimental implementation of tjhe proc mod exists, refer to Simple, and avoid giving the impression that the proc mod is ready for prime time use by anyone else! On 06/02/16 11:05, Magdalena Turska wrote:
Poligon is no longer relevant, as I did reorganize the repo a bit, so procmod xslts ended up here https://github.com/TEIC/TEI-Simple/tree/master/processingModel
The simplest way to use xslt version is to take your ODD and run simpleoddtoxsl.xsl on in
saxon -xi -s:my.odd -o:simple.xsl -xsl:simpleoddtoxsl.xsl
Which should generate a stylesheet that one could use for transformation of tei files.
The fragments that 'knows about behaviours' are https://github.com/TEIC/TEI-Simple/blob/master/processingModel/html_function... (for transforms into html) and latex_functions.xsl (dunno how complete this one is). So these files are where the behaviours definitions live, while actual magic that controls the whole process happens in polygon_lib.xsl
Therefore the easiest way to do the tests of type 3. would be to take current teisimple.odd, generate output xsl as shown above and store it as expected result.
M
On 28 January 2016 at 11:42, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
Hi Magda
OK I will carry on producing some simple test files for (1).
On (2) I'm not sure why you mention sample Simple files here: I think that's a separate exercise. Obviously we will need to revisit them when we start work on the TEI Simple Exemplar: but you shouldn't let that stop you working your magic!
How exactly do we do number 3? You havent answered my question about the Stylesheet implications: is there somewhere a fragment of XSLT which knows about the proposed "behaviours" which we can integrate into the Stylesheet library?
And thanks for explaining the poligon!
L
On 28/01/16 10:48, Magdalena Turska wrote:
Hi,
as for test files, I guess we should test roughly three classes of things 1. as you pointed out, that sample ODDs including <model> elements do validate against TEI schemas 2. sample TEI Simple files can be converted into output using processing model and this output is as expected (test files for this are in https://github.com/TEIC/TEI-Simple/tree/master/tests, let me clear them up a bit and provide you with magic commands for executing the tests) 3. tests that sample ODDs get converted into expected XSLTs/XQueries by processing model
2 is already in place, or almost, 1 most probably straightforward for Lou or James and I guess even I could do it if I had an afternoon to kill. We have nothing for 3 as yet, though what we could easily do is take the ODD we have and results of application of current processing model implementations as our expected output.
To satiate your curiosity: "poligon" in Polish means military training area, where you can shoot and run soldiers around without causing collateral damage. The closest English word (in looks, not meaning, though I believe the roots of the Polish and English words are indeed the same) is polygon, so that's how it got to be named like that. Sorry if it tells too much about my mental processes.
I am trying to keep afloat and not to sink under pressing work obligations, but if I took to it early next week would that be acceptable for you?
Magdalena
On 28 January 2016 at 10:22, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
The next step in getting procmod into the Guidelines ought to be to
produce some test files. However, as James mentioned earlier, this is not entirely straightforward.
I can dream up sample ODDs which include <model> elements no problem, and can then validate them against the schemas generated from the current source. I can also re-use the ones in the Polygon directory in the original tei-simple repo, written by Magdalena. (why is it called "Polygon" btw?)
However, should we not also be producing a test implementation or two showing the actual output generated with the aid of those models? That would require adding, presumably into the Stylesheets tree, some version of Magda's pilot version of a stylesheet for transforming <model>s into XSL. Or is that already there somewhere?
Or are we just planning to keep quiet about the whole thing?
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
There is a third way as well: disentangle from Simple, but not necessarily integrate with TEI Stylesheets. Frankly, I don't know what the latter would mean? I can imagine making TEI Stylesheets use procmod for generating a significant portion of itself in the future, but not really the other way around. Unless you just mean, lets carve a small corner of TEI Stylesheet repo for procmod, which is easy enough to do and shouldn't cause any headaches. On 6 February 2016 at 12:24, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
Thanks, that clarifies my question below.
There is quite a big policy decision here though. Do we want to disentangle the processing model processing tools from simple and integrate them properly into the existing stylesheets library?
If we do, that's work we ought to do in tandem with defining the proc mod spec in the Guidelines.
If we don't then the proc mod spec ought simply to say that an experimental implementation of tjhe proc mod exists, refer to Simple, and avoid giving the impression that the proc mod is ready for prime time use by anyone else!
On 06/02/16 11:05, Magdalena Turska wrote:
Poligon is no longer relevant, as I did reorganize the repo a bit, so procmod xslts ended up here https://github.com/TEIC/TEI-Simple/tree/master/processingModel
The simplest way to use xslt version is to take your ODD and run simpleoddtoxsl.xsl on in
saxon -xi -s:my.odd -o:simple.xsl -xsl:simpleoddtoxsl.xsl
Which should generate a stylesheet that one could use for transformation of tei files.
The fragments that 'knows about behaviours' are
https://github.com/TEIC/TEI-Simple/blob/master/processingModel/html_function... (for transforms into html) and latex_functions.xsl (dunno how complete this one is). So these files are where the behaviours definitions live, while actual magic that controls the whole process happens in polygon_lib.xsl
Therefore the easiest way to do the tests of type 3. would be to take current teisimple.odd, generate output xsl as shown above and store it as expected result.
M
On 28 January 2016 at 11:42, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
Hi Magda
OK I will carry on producing some simple test files for (1).
On (2) I'm not sure why you mention sample Simple files here: I think that's a separate exercise. Obviously we will need to revisit them when we start work on the TEI Simple Exemplar: but you shouldn't let that stop you working your magic!
How exactly do we do number 3? You havent answered my question about the Stylesheet implications: is there somewhere a fragment of XSLT which knows about the proposed "behaviours" which we can integrate into the Stylesheet library?
And thanks for explaining the poligon!
L
On 28/01/16 10:48, Magdalena Turska wrote:
Hi,
as for test files, I guess we should test roughly three classes of things 1. as you pointed out, that sample ODDs including <model> elements do validate against TEI schemas 2. sample TEI Simple files can be converted into output using processing model and this output is as expected (test files for this are in https://github.com/TEIC/TEI-Simple/tree/master/tests, let me clear them up a bit and provide you with magic commands for executing the tests) 3. tests that sample ODDs get converted into expected XSLTs/XQueries by processing model
2 is already in place, or almost, 1 most probably straightforward for Lou or James and I guess even I could do it if I had an afternoon to kill. We have nothing for 3 as yet, though what we could easily do is take the ODD we have and results of application of current processing model implementations as our expected output.
To satiate your curiosity: "poligon" in Polish means military training area, where you can shoot and run soldiers around without causing collateral damage. The closest English word (in looks, not meaning, though I believe the roots of the Polish and English words are indeed the same) is polygon, so that's how it got to be named like that. Sorry if it tells too much about my mental processes.
I am trying to keep afloat and not to sink under pressing work obligations, but if I took to it early next week would that be acceptable for you?
Magdalena
On 28 January 2016 at 10:22, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
The next step in getting procmod into the Guidelines ought to be to
produce some test files. However, as James mentioned earlier, this is not entirely straightforward.
I can dream up sample ODDs which include <model> elements no problem, and can then validate them against the schemas generated from the current source. I can also re-use the ones in the Polygon directory in the original tei-simple repo, written by Magdalena. (why is it called "Polygon" btw?)
However, should we not also be producing a test implementation or two showing the actual output generated with the aid of those models? That would require adding, presumably into the Stylesheets tree, some version of Magda's pilot version of a stylesheet for transforming <model>s into XSL. Or is that already there somewhere?
Or are we just planning to keep quiet about the whole thing?
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
--
tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
By "integrate properly" I didn't mean any more than find a corner to put them so that people who download the Stylesheets library get the ability to process proc mods as well. In much the same way as the Stylesheet library now also ODD processing built in. But your third way is also possible, if the Council wants the chore of maintaining yet another package. On 06/02/16 12:49, Magdalena Turska wrote:
There is a third way as well: disentangle from Simple, but not necessarily integrate with TEI Stylesheets. Frankly, I don't know what the latter would mean? I can imagine making TEI Stylesheets use procmod for generating a significant portion of itself in the future, but not really the other way around. Unless you just mean, lets carve a small corner of TEI Stylesheet repo for procmod, which is easy enough to do and shouldn't cause any headaches.
On 6 February 2016 at 12:24, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
Thanks, that clarifies my question below.
There is quite a big policy decision here though. Do we want to disentangle the processing model processing tools from simple and integrate them properly into the existing stylesheets library?
If we do, that's work we ought to do in tandem with defining the proc mod spec in the Guidelines.
If we don't then the proc mod spec ought simply to say that an experimental implementation of tjhe proc mod exists, refer to Simple, and avoid giving the impression that the proc mod is ready for prime time use by anyone else!
On 06/02/16 11:05, Magdalena Turska wrote:
Poligon is no longer relevant, as I did reorganize the repo a bit, so procmod xslts ended up here https://github.com/TEIC/TEI-Simple/tree/master/processingModel
The simplest way to use xslt version is to take your ODD and run simpleoddtoxsl.xsl on in
saxon -xi -s:my.odd -o:simple.xsl -xsl:simpleoddtoxsl.xsl
Which should generate a stylesheet that one could use for transformation of tei files.
The fragments that 'knows about behaviours' are
https://github.com/TEIC/TEI-Simple/blob/master/processingModel/html_function... (for transforms into html) and latex_functions.xsl (dunno how complete this one is). So these files are where the behaviours definitions live, while actual magic that controls the whole process happens in polygon_lib.xsl
Therefore the easiest way to do the tests of type 3. would be to take current teisimple.odd, generate output xsl as shown above and store it as expected result.
M
On 28 January 2016 at 11:42, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
Hi Magda
OK I will carry on producing some simple test files for (1).
On (2) I'm not sure why you mention sample Simple files here: I think that's a separate exercise. Obviously we will need to revisit them when we start work on the TEI Simple Exemplar: but you shouldn't let that stop you working your magic!
How exactly do we do number 3? You havent answered my question about the Stylesheet implications: is there somewhere a fragment of XSLT which knows about the proposed "behaviours" which we can integrate into the Stylesheet library?
And thanks for explaining the poligon!
L
On 28/01/16 10:48, Magdalena Turska wrote:
Hi,
as for test files, I guess we should test roughly three classes of things 1. as you pointed out, that sample ODDs including <model> elements do validate against TEI schemas 2. sample TEI Simple files can be converted into output using processing model and this output is as expected (test files for this are in https://github.com/TEIC/TEI-Simple/tree/master/tests, let me clear them up a bit and provide you with magic commands for executing the tests) 3. tests that sample ODDs get converted into expected XSLTs/XQueries by processing model
2 is already in place, or almost, 1 most probably straightforward for Lou or James and I guess even I could do it if I had an afternoon to kill. We have nothing for 3 as yet, though what we could easily do is take the ODD we have and results of application of current processing model implementations as our expected output.
To satiate your curiosity: "poligon" in Polish means military training area, where you can shoot and run soldiers around without causing collateral damage. The closest English word (in looks, not meaning, though I believe the roots of the Polish and English words are indeed the same) is polygon, so that's how it got to be named like that. Sorry if it tells too much about my mental processes.
I am trying to keep afloat and not to sink under pressing work obligations, but if I took to it early next week would that be acceptable for you?
Magdalena
On 28 January 2016 at 10:22, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
The next step in getting procmod into the Guidelines ought to be to
produce some test files. However, as James mentioned earlier, this is not entirely straightforward.
I can dream up sample ODDs which include <model> elements no problem, and can then validate them against the schemas generated from the current source. I can also re-use the ones in the Polygon directory in the original tei-simple repo, written by Magdalena. (why is it called "Polygon" btw?)
However, should we not also be producing a test implementation or two showing the actual output generated with the aid of those models? That would require adding, presumably into the Stylesheets tree, some version of Magda's pilot version of a stylesheet for transforming <model>s into XSL. Or is that already there somewhere?
Or are we just planning to keep quiet about the whole thing?
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
I've made a start on testing this, but I think it's going to be a long job. I made a new git repo for it since it's not clear where this stuff goes (if anywhere) : https://github.com/lb42/lb42-testprocmod This includes a sample ODD that is meant to exercise all the behaviours currently defined, and copies of Magdalena's cunning XSL scripts for converting that to XSLT that should produce HTML or maybe LaTeX from a TEI XML file (probably using a subset of TEI Simple, but that's not what this is trying to test) It doesn't work of course, but that's probably my fault. However, I now have to go shopping or there'll be no bread for breakfast tomorrow. In the proc mod branch On 06/02/16 12:56, Lou Burnard wrote:
By "integrate properly" I didn't mean any more than find a corner to put them so that people who download the Stylesheets library get the ability to process proc mods as well. In much the same way as the Stylesheet library now also ODD processing built in. But your third way is also possible, if the Council wants the chore of maintaining yet another package.
On 06/02/16 12:49, Magdalena Turska wrote:
There is a third way as well: disentangle from Simple, but not necessarily integrate with TEI Stylesheets. Frankly, I don't know what the latter would mean? I can imagine making TEI Stylesheets use procmod for generating a significant portion of itself in the future, but not really the other way around. Unless you just mean, lets carve a small corner of TEI Stylesheet repo for procmod, which is easy enough to do and shouldn't cause any headaches.
On 6 February 2016 at 12:24, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
Thanks, that clarifies my question below.
There is quite a big policy decision here though. Do we want to disentangle the processing model processing tools from simple and integrate them properly into the existing stylesheets library?
If we do, that's work we ought to do in tandem with defining the proc mod spec in the Guidelines.
If we don't then the proc mod spec ought simply to say that an experimental implementation of tjhe proc mod exists, refer to Simple, and avoid giving the impression that the proc mod is ready for prime time use by anyone else!
On 06/02/16 11:05, Magdalena Turska wrote:
Poligon is no longer relevant, as I did reorganize the repo a bit, so procmod xslts ended up here https://github.com/TEIC/TEI-Simple/tree/master/processingModel
The simplest way to use xslt version is to take your ODD and run simpleoddtoxsl.xsl on in
saxon -xi -s:my.odd -o:simple.xsl -xsl:simpleoddtoxsl.xsl
Which should generate a stylesheet that one could use for transformation of tei files.
The fragments that 'knows about behaviours' are
https://github.com/TEIC/TEI-Simple/blob/master/processingModel/html_function...
(for transforms into html) and latex_functions.xsl (dunno how complete this one is). So these files are where the behaviours definitions live, while actual magic that controls the whole process happens in polygon_lib.xsl
Therefore the easiest way to do the tests of type 3. would be to take current teisimple.odd, generate output xsl as shown above and store it as expected result.
M
On 28 January 2016 at 11:42, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
Hi Magda
OK I will carry on producing some simple test files for (1).
On (2) I'm not sure why you mention sample Simple files here: I think that's a separate exercise. Obviously we will need to revisit them when we start work on the TEI Simple Exemplar: but you shouldn't let that stop you working your magic!
How exactly do we do number 3? You havent answered my question about the Stylesheet implications: is there somewhere a fragment of XSLT which knows about the proposed "behaviours" which we can integrate into the Stylesheet library?
And thanks for explaining the poligon!
L
On 28/01/16 10:48, Magdalena Turska wrote:
Hi,
as for test files, I guess we should test roughly three classes of things 1. as you pointed out, that sample ODDs including <model> elements do validate against TEI schemas 2. sample TEI Simple files can be converted into output using processing model and this output is as expected (test files for this are in https://github.com/TEIC/TEI-Simple/tree/master/tests, let me clear them up a bit and provide you with magic commands for executing the tests) 3. tests that sample ODDs get converted into expected XSLTs/XQueries by processing model
2 is already in place, or almost, 1 most probably straightforward for Lou or James and I guess even I could do it if I had an afternoon to kill. We have nothing for 3 as yet, though what we could easily do is take the ODD we have and results of application of current processing model implementations as our expected output.
To satiate your curiosity: "poligon" in Polish means military training area, where you can shoot and run soldiers around without causing collateral damage. The closest English word (in looks, not meaning, though I believe the roots of the Polish and English words are indeed the same) is polygon, so that's how it got to be named like that. Sorry if it tells too much about my mental processes.
I am trying to keep afloat and not to sink under pressing work obligations, but if I took to it early next week would that be acceptable for you?
Magdalena
On 28 January 2016 at 10:22, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
The next step in getting procmod into the Guidelines ought to be to
> produce some test files. However, as James mentioned earlier, > this is > not > entirely straightforward. > > I can dream up sample ODDs which include <model> elements no > problem, > and > can then validate them against the schemas generated from the > current > source. I can also re-use the ones in the Polygon > directory in the original tei-simple repo, written by Magdalena. > (why > is > it called "Polygon" btw?) > > However, should we not also be producing a test implementation > or two > showing the actual output generated with the aid of those > models? That > would require adding, presumably into the Stylesheets tree, > some version of Magda's pilot version of a stylesheet for > transforming > <model>s into XSL. Or is that already there somewhere? > > Or are we just planning to keep quiet about the whole thing? > > -- > tei-council mailing list > tei-council@lists.tei-c.org > http://lists.lists.tei-c.org/mailman/listinfo/tei-council > > PLEASE NOTE: postings to this list are publicly archived > > > -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
In your testprocmod.odd there are 3 issues: - one more or less your fault: link behaviour expects link param, not uri - one a bit tricky, atm note behaviour expects to have label param, I wonder if we should have a default there, see https://github.com/TEIC/TEI-Simple/issues/28 - one definitely a bug on the cunning stylesheet side, figure behaviour produces invalid xslt template and so far I don't know why... On 6 February 2016 at 15:25, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
I've made a start on testing this, but I think it's going to be a long job.
I made a new git repo for it since it's not clear where this stuff goes (if anywhere) :
https://github.com/lb42/lb42-testprocmod
This includes a sample ODD that is meant to exercise all the behaviours currently defined, and copies of Magdalena's cunning XSL scripts for converting that to XSLT that should produce HTML or maybe LaTeX from a TEI XML file (probably using a subset of TEI Simple, but that's not what this is trying to test)
It doesn't work of course, but that's probably my fault. However, I now have to go shopping or there'll be no bread for breakfast tomorrow.
In the proc mod branch
On 06/02/16 12:56, Lou Burnard wrote:
By "integrate properly" I didn't mean any more than find a corner to put them so that people who download the Stylesheets library get the ability to process proc mods as well. In much the same way as the Stylesheet library now also ODD processing built in. But your third way is also possible, if the Council wants the chore of maintaining yet another package.
On 06/02/16 12:49, Magdalena Turska wrote:
There is a third way as well: disentangle from Simple, but not necessarily integrate with TEI Stylesheets. Frankly, I don't know what the latter would mean? I can imagine making TEI Stylesheets use procmod for generating a significant portion of itself in the future, but not really the other way around. Unless you just mean, lets carve a small corner of TEI Stylesheet repo for procmod, which is easy enough to do and shouldn't cause any headaches.
On 6 February 2016 at 12:24, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
Thanks, that clarifies my question below.
There is quite a big policy decision here though. Do we want to disentangle the processing model processing tools from simple and integrate them properly into the existing stylesheets library?
If we do, that's work we ought to do in tandem with defining the proc mod spec in the Guidelines.
If we don't then the proc mod spec ought simply to say that an experimental implementation of tjhe proc mod exists, refer to Simple, and avoid giving the impression that the proc mod is ready for prime time use by anyone else!
On 06/02/16 11:05, Magdalena Turska wrote:
Poligon is no longer relevant, as I did reorganize the repo a bit, so
procmod xslts ended up here https://github.com/TEIC/TEI-Simple/tree/master/processingModel
The simplest way to use xslt version is to take your ODD and run simpleoddtoxsl.xsl on in
saxon -xi -s:my.odd -o:simple.xsl -xsl:simpleoddtoxsl.xsl
Which should generate a stylesheet that one could use for transformation of tei files.
The fragments that 'knows about behaviours' are
https://github.com/TEIC/TEI-Simple/blob/master/processingModel/html_function... (for transforms into html) and latex_functions.xsl (dunno how complete this one is). So these files are where the behaviours definitions live, while actual magic that controls the whole process happens in polygon_lib.xsl
Therefore the easiest way to do the tests of type 3. would be to take current teisimple.odd, generate output xsl as shown above and store it as expected result.
M
On 28 January 2016 at 11:42, Lou Burnard <lou.burnard@retired.ox.ac.uk
wrote:
Hi Magda
OK I will carry on producing some simple test files for (1).
On (2) I'm not sure why you mention sample Simple files here: I think that's a separate exercise. Obviously we will need to revisit them when we start work on the TEI Simple Exemplar: but you shouldn't let that stop you working your magic!
How exactly do we do number 3? You havent answered my question about the Stylesheet implications: is there somewhere a fragment of XSLT which knows about the proposed "behaviours" which we can integrate into the Stylesheet library?
And thanks for explaining the poligon!
L
On 28/01/16 10:48, Magdalena Turska wrote:
Hi,
> as for test files, I guess we should test roughly three classes of > things > 1. as you pointed out, that sample ODDs including <model> elements do > validate against TEI schemas > 2. sample TEI Simple files can be converted into output using > processing > model and this output is as expected (test files for this are in > https://github.com/TEIC/TEI-Simple/tree/master/tests, let me clear > them > up > a bit and provide you with magic commands for executing the tests) > 3. tests that sample ODDs get converted into expected XSLTs/XQueries > by > processing model > > 2 is already in place, or almost, 1 most probably straightforward for > Lou > or James and I guess even I could do it if I had an afternoon to > kill. > We > have nothing for 3 as yet, though what we could easily do is take the > ODD > we have and results of application of current processing model > implementations as our expected output. > > To satiate your curiosity: "poligon" in Polish means military > training > area, where you can shoot and run soldiers around without causing > collateral damage. The closest English word (in looks, not meaning, > though > I believe the roots of the Polish and English words are indeed the > same) > is > polygon, so that's how it got to be named like that. Sorry if it > tells > too > much about my mental processes. > > I am trying to keep afloat and not to sink under pressing work > obligations, > but if I took to it early next week would that be acceptable for you? > > Magdalena > > On 28 January 2016 at 10:22, Lou Burnard < > lou.burnard@retired.ox.ac.uk> > wrote: > > The next step in getting procmod into the Guidelines ought to be to > > produce some test files. However, as James mentioned earlier, this is >> not >> entirely straightforward. >> >> I can dream up sample ODDs which include <model> elements no >> problem, >> and >> can then validate them against the schemas generated from the >> current >> source. I can also re-use the ones in the Polygon >> directory in the original tei-simple repo, written by Magdalena. >> (why >> is >> it called "Polygon" btw?) >> >> However, should we not also be producing a test implementation or >> two >> showing the actual output generated with the aid of those models? >> That >> would require adding, presumably into the Stylesheets tree, >> some version of Magda's pilot version of a stylesheet for >> transforming >> <model>s into XSL. Or is that already there somewhere? >> >> Or are we just planning to keep quiet about the whole thing? >> >> -- >> tei-council mailing list >> tei-council@lists.tei-c.org >> http://lists.lists.tei-c.org/mailman/listinfo/tei-council >> >> PLEASE NOTE: postings to this list are publicly archived >> >> >> -- >> > tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
On 07/02/16 19:30, Magdalena Turska wrote:
In your testprocmod.odd there are 3 issues: - one more or less your fault: link behaviour expects link param, not uri
Yes. This one is part of my general failure to understand how parameters work : I assume if I see an attribute @name="xxxx" that I can use whatever value I like. If not, shouldn't there be a <valList> somewhere with documented valItems? Is it the TEI that decides what these @name values (or some of them) should be, and what they mean, or is it just something in your stylesheets? If the latter, obviously another procmod processor might expect different names.
Right, this is underspecified atm. We need list of expected params and their types for every behaviour; in cases where params invoke some special magic embedded in the function (as is the case eg with place on note behaviour), a list of available values. On 7 February 2016 at 19:50, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
On 07/02/16 19:30, Magdalena Turska wrote:
In your testprocmod.odd there are 3 issues: - one more or less your fault: link behaviour expects link param, not uri
Yes. This one is part of my general failure to understand how parameters work : I assume if I see an attribute @name="xxxx" that I can use whatever value I like. If not, shouldn't there be a <valList> somewhere with documented valItems?
Is it the TEI that decides what these @name values (or some of them) should be, and what they mean, or is it just something in your stylesheets? If the latter, obviously another procmod processor might expect different names.
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
It would be much easier if the names of parameters were global, i.e. if <param name="foo"> always had the same meaning no matter what behaviour it was associated with. Then we could define this list as a <valList> inside the spec for param/@name. On 07/02/16 19:57, Magdalena Turska wrote:
Right, this is underspecified atm. We need list of expected params and their types for every behaviour; in cases where params invoke some special magic embedded in the function (as is the case eg with place on note behaviour), a list of available values.
On 7 February 2016 at 19:50, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
On 07/02/16 19:30, Magdalena Turska wrote:
In your testprocmod.odd there are 3 issues: - one more or less your fault: link behaviour expects link param, not uri
Yes. This one is part of my general failure to understand how parameters work : I assume if I see an attribute @name="xxxx" that I can use whatever value I like. If not, shouldn't there be a <valList> somewhere with documented valItems?
Is it the TEI that decides what these @name values (or some of them) should be, and what they mean, or is it just something in your stylesheets? If the latter, obviously another procmod processor might expect different names.
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
Probably best just to try it. I have rather vague idea how to go about it*, but perhaps this is a good occasion to learn. Only afraid I may not have too much time during the week again. [*] meaning I don't have any except to try and dig in the guidelines :-) On 7 February 2016 at 20:05, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
It would be much easier if the names of parameters were global, i.e. if <param name="foo"> always had the same meaning no matter what behaviour it was associated with. Then we could define this list as a <valList> inside the spec for param/@name.
On 07/02/16 19:57, Magdalena Turska wrote:
Right, this is underspecified atm. We need list of expected params and their types for every behaviour; in cases where params invoke some special magic embedded in the function (as is the case eg with place on note behaviour), a list of available values.
On 7 February 2016 at 19:50, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
On 07/02/16 19:30, Magdalena Turska wrote:
In your testprocmod.odd there are 3 issues:
- one more or less your fault: link behaviour expects link param, not uri
Yes. This one is part of my general failure to understand how parameters work : I assume if I see an attribute @name="xxxx" that I can use whatever value I like. If not, shouldn't there be a <valList> somewhere with documented valItems?
Is it the TEI that decides what these @name values (or some of them) should be, and what they mean, or is it just something in your stylesheets? If the latter, obviously another procmod processor might expect different names.
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
I can have a stab at this later but not till after the last episode of war and peace on telly tonight! Sent from my Samsung Galaxy Tab®|PRO -------- Original message -------- From: Magdalena Turska Date:2016/02/07 20:12 (GMT+00:00) To: tei-council@lists.tei-c.org Subject: Re: [tei-council] processing the processing model Probably best just to try it. I have rather vague idea how to go about it*, but perhaps this is a good occasion to learn. Only afraid I may not have too much time during the week again. [*] meaning I don't have any except to try and dig in the guidelines :-) On 7 February 2016 at 20:05, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
It would be much easier if the names of parameters were global, i.e. if <param name="foo"> always had the same meaning no matter what behaviour it was associated with. Then we could define this list as a <valList> inside the spec for param/@name.
On 07/02/16 19:57, Magdalena Turska wrote:
Right, this is underspecified atm. We need list of expected params and their types for every behaviour; in cases where params invoke some special magic embedded in the function (as is the case eg with place on note behaviour), a list of available values.
On 7 February 2016 at 19:50, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
On 07/02/16 19:30, Magdalena Turska wrote:
In your testprocmod.odd there are 3 issues:
- one more or less your fault: link behaviour expects link param, not uri
Yes. This one is part of my general failure to understand how parameters work : I assume if I see an attribute @name="xxxx" that I can use whatever value I like. If not, shouldn't there be a <valList> somewhere with documented valItems?
Is it the TEI that decides what these @name values (or some of them) should be, and what they mean, or is it just something in your stylesheets? If the latter, obviously another procmod processor might expect different names.
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council PLEASE NOTE: postings to this list are publicly archived
Places to look then are: polygon_lib.xsl//xsl:function[@name='tei:matchFunction'] where you will find cases like: <xsl:when test="$task ='alternate'"> <xsl:sequence select="tei:alternate($model, tei:getParam($model,'default'), tei:getParam($model,'alternate'),$class, $number)"/> </xsl:when> where it is easiest to observe what tei:getParam calls there actually are. Looking at html_functions.xsl can be rather misleading as param names there are not necessarily in line with those from polygon_lib :-/ On 7 February 2016 at 20:33, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
I can have a stab at this later but not till after the last episode of war and peace on telly tonight!
Sent from my Samsung Galaxy Tab®|PRO
-------- Original message -------- From: Magdalena Turska Date:2016/02/07 20:12 (GMT+00:00) To: tei-council@lists.tei-c.org Subject: Re: [tei-council] processing the processing model
Probably best just to try it. I have rather vague idea how to go about it*, but perhaps this is a good occasion to learn. Only afraid I may not have too much time during the week again.
[*] meaning I don't have any except to try and dig in the guidelines :-)
On 7 February 2016 at 20:05, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
It would be much easier if the names of parameters were global, i.e. if <param name="foo"> always had the same meaning no matter what behaviour it was associated with. Then we could define this list as a <valList> inside the spec for param/@name.
On 07/02/16 19:57, Magdalena Turska wrote:
Right, this is underspecified atm. We need list of expected params and their types for every behaviour; in cases where params invoke some special magic embedded in the function (as is the case eg with place on note behaviour), a list of available values.
On 7 February 2016 at 19:50, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
On 07/02/16 19:30, Magdalena Turska wrote:
In your testprocmod.odd there are 3 issues:
- one more or less your fault: link behaviour expects link param, not uri
Yes. This one is part of my general failure to understand how
parameters
work : I assume if I see an attribute @name="xxxx" that I can use whatever value I like. If not, shouldn't there be a <valList> somewhere with documented valItems?
Is it the TEI that decides what these @name values (or some of them) should be, and what they mean, or is it just something in your stylesheets? If the latter, obviously another procmod processor might expect different names.
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
<attDef ident="name" usage="req"> <desc versionDate="2015-08-21" xml:lang="en">Name of parameter</desc> <datatype><dataRef key="teidata.enumerated"/></datatype> <!-- these are all the different param/@name values which polygon knows about--> <valList type="closed"><!-- or semi? --> <valItem ident='alternate'/> <valItem ident='content'/> <valItem ident='default'/> <valItem ident='height'/> <valItem ident='id'/> <valItem ident='label'/> <valItem ident='level'/> <valItem ident='link'/> <valItem ident='place'/> <valItem ident='scale'/> <valItem ident='type'/> <valItem ident='url'/> <valItem ident='width'/> </valList> </attDef> On 07/02/16 20:39, Magdalena Turska wrote:
Places to look then are: polygon_lib.xsl//xsl:function[@name='tei:matchFunction'] where you will find cases like: <xsl:when test="$task ='alternate'"> <xsl:sequence select="tei:alternate($model, tei:getParam($model,'default'), tei:getParam($model,'alternate'),$class, $number)"/> </xsl:when>
where it is easiest to observe what tei:getParam calls there actually are. Looking at html_functions.xsl can be rather misleading as param names there are not necessarily in line with those from polygon_lib :-/
On 7 February 2016 at 20:33, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
I can have a stab at this later but not till after the last episode of war and peace on telly tonight!
Sent from my Samsung Galaxy Tab®|PRO
-------- Original message -------- From: Magdalena Turska Date:2016/02/07 20:12 (GMT+00:00) To: tei-council@lists.tei-c.org Subject: Re: [tei-council] processing the processing model
Probably best just to try it. I have rather vague idea how to go about it*, but perhaps this is a good occasion to learn. Only afraid I may not have too much time during the week again.
[*] meaning I don't have any except to try and dig in the guidelines :-)
On 7 February 2016 at 20:05, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
It would be much easier if the names of parameters were global, i.e. if <param name="foo"> always had the same meaning no matter what behaviour it was associated with. Then we could define this list as a <valList> inside the spec for param/@name.
On 07/02/16 19:57, Magdalena Turska wrote:
Right, this is underspecified atm. We need list of expected params and their types for every behaviour; in cases where params invoke some special magic embedded in the function (as is the case eg with place on note behaviour), a list of available values. On 7 February 2016 at 19:50, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
In your testprocmod.odd there are 3 issues:
- one more or less your fault: link behaviour expects link param, not uri
Yes. This one is part of my general failure to understand how
On 07/02/16 19:30, Magdalena Turska wrote: parameters
work : I assume if I see an attribute @name="xxxx" that I can use whatever value I like. If not, shouldn't there be a <valList> somewhere with documented valItems?
Is it the TEI that decides what these @name values (or some of them) should be, and what they mean, or is it just something in your stylesheets? If the latter, obviously another procmod processor might expect different names.
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
I've done some minor revision of the TD chapter in the lb42-procmod chapter, addressing (I hope) some of Magdalena's concerns, though probably not all of them. Unfortunately I reformatted the whole chapter with Oxygen, making it hard to see exactly what I've changed, but it wasn't a lot, honest. I also added a <valList> to the param/@name attribute, and added the proposed model/@cssClass attribute. I'm still confused about how <param> is supposed to work though. And the procmodtest still doesn't work. Over to you, Magdalena!
Thanks Lou, was trying to fight the bug in procmod stylesheet on Sunday, I know what the issue is but my fix broke it in other places. Oh well, I do miss Sebastian a lot. Will bang my head on the wall a little and try again over next couple of days. On 9 February 2016 at 19:11, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
I've done some minor revision of the TD chapter in the lb42-procmod chapter, addressing (I hope) some of Magdalena's concerns, though probably not all of them. Unfortunately I reformatted the whole chapter with Oxygen, making it hard to see exactly what I've changed, but it wasn't a lot, honest.
I also added a <valList> to the param/@name attribute, and added the proposed model/@cssClass attribute.
I'm still confused about how <param> is supposed to work though. And the procmodtest still doesn't work. Over to you, Magdalena!
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
Apologies for the delay, here are results of my investigation what are parameters for existing behaviours. As a general rule, any XPath expression is allowed as parameter value, though sometimes these expressions are just strings like 'bottom' or 'page', quoted to mean literal string in XPath. Thus all parameters have XPath datatype, but of course expected results for expressions that these XPaths evaluate to are different depending on the behaviour/parameter pair. <!-- these are all the different param/@name values which polygon knows about--> <valList type="closed"><!-- or semi? --> <valItem ident='alternate'/> expression pointing at content to process as alternative (eg. for options wrapped in choice); only used for behaviour="alternate" <valItem ident='content'/> expression pointing at content to process in a behaviour (common for all behaviours with the exception of alternate and omit); only parameter so far that *has* default value (being currently processed element) <valItem ident='default'/> same as content but used only for behaviour="alternate" <valItem ident='height'/> should evaluate to something that can be used as a value for @height attribute on html:img; used for behaviour="graphic" <valItem ident='id'/> expression that should evaluate to something that could be used as identifiers for an anchor, so similar to url/link but only for linking within the same document; used only for behaviour="anchor" <valItem ident='label'/> expression that should evaluate to something that could be used as label for breaks (eg. concat('Page ', @n) would produce labels like 'Page 1', 'Page 2' etc; used only for behaviour="break" <valItem ident='level'/> should evaluate to a positive integer, used on behaviour="heading" to specify its level <valItem ident='link'/> expression pointing where to find content to be used as URL for hyperlink generated with behaviour="link" <valItem ident='place'/> expression (quite often just literal string, but XPath expression nevertheless) that should evaluate to a name of the location for the note generated; in current xslt implementation if it evaluates to 'bottom' it gets special treatment, an anchor linking to a div containing the actual note, all others are enclosed in spans (don't ask me why); used only on behaviour="note" <valItem ident='scale'/> present on parameter list for behaviour="graphic" but not used at all <valItem ident='type'/> envisioned to be used to specify the kind of break to perform (when used on behaviour="break") or index to generate (if used on behaviour="index") <valItem ident='url'/> same as link but used for behaviour="graphic" to be used as a value of img/@src when transforming to html <valItem ident='width'/> same as height but, of course, for width </valList> On 9 February 2016 at 22:32, Magdalena Turska <tuurma@gmail.com> wrote:
Thanks Lou, was trying to fight the bug in procmod stylesheet on Sunday, I know what the issue is but my fix broke it in other places. Oh well, I do miss Sebastian a lot. Will bang my head on the wall a little and try again over next couple of days.
On 9 February 2016 at 19:11, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
I've done some minor revision of the TD chapter in the lb42-procmod chapter, addressing (I hope) some of Magdalena's concerns, though probably not all of them. Unfortunately I reformatted the whole chapter with Oxygen, making it hard to see exactly what I've changed, but it wasn't a lot, honest.
I also added a <valList> to the param/@name attribute, and added the proposed model/@cssClass attribute.
I'm still confused about how <param> is supposed to work though. And the procmodtest still doesn't work. Over to you, Magdalena!
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
participants (2)
-
Lou Burnard -
Magdalena Turska