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