Stylesheets default handling of tei:milestone not very useful
merged today
Pull request created: https://github.com/EpiDoc/Stylesheets/pull/18 Note: same as described before, except for the spaces flanking the pipe '|' when not inword that was preserved in the final fix.
I'm not ready. I think we should postpone it.
That's seems coherent to me. Here's how I would translate this solution in the XSL files: teimilestone.xsl display a pipe when @unit is 'fragment' or 'block' -- no spaces around if @n exists, displays as exposant <xsl:template match="t:milestone[@unit='block' or @unit='fragment']"> <!-- adds pipe for block or fragment--> <xsl:text>|</xsl:text> <xsl:if test="@n"> <sup><xsl:value-of select="@n"/></sup> </xsl:if> </xsl:template> instead of: <xsl:template match="t:milestone[@unit='block' or @unit='fragment']">...
That's seems coherent to me. Here's how I would translate this solution in the XSL files: teimilestone.xsl display a pipe when @unit is 'fragment' or 'block' -- no spaces around if @n exists, displays as exposant ~~~ <xsl:template match="t:milestone<span>[klzzwxh:0002='block' or klzzwxh:0003='fragment']</span>"> <xsl:text>|</xsl:text> <xsl:if test="@n"> <xsl:value-of select="@n"></xsl:value-of> </xsl:if> </xsl:template> ~~~ instead of: <xsl:template match="t:milestone[@unit='block'...
That's seems coherent to me. Here's how I would translate this solution in the XSL files: teimilestone.xsl display a pipe when @unit is 'fragment' or 'block' -- no spaces around if @n exists, displays as exposant ~~~ <xsl:template match="t:milestone<span>[klzzwxh:0002='block' or klzzwxh:0003='fragment']</span>"> <xsl:text>|</xsl:text> <xsl:if test="@n"> <xsl:value-of select="@n"></xsl:value-of> </xsl:if> </xsl:template> instead of: <xsl:template match="t:milestone<span>[klzzwxh:0022='block'...
That's seems coherent to me. Here's how I would translate this solution in the XSL files: teimilestone.xsl display a pipe when @unit is 'fragment' or 'block' -- no spaces around if @n exists, displays as exposant ~~~ <xsl:template match="t:milestone<span>[klzzwxh:0052='block' or klzzwxh:0053='fragment']</span>"> <xsl:text>|</xsl:text> <xsl:if test="@n"> <xsl:value-of select="@n"></xsl:value-of> </xsl:if> </xsl:template> instead of: <xsl:template match="t:milestone<span>[klzzwxh:0001='block'...
That's seems coherent to me. Here's how I would translate this solution in the XSL files: teimilestone.xsl display a pipe when @unit is 'fragment' or 'block' -- no spaces around if @n exists, displays as exposant ~~~ <xsl:template match="t:milestone<span>[klzzwxh:0052='block' or klzzwxh:0053='fragment']</span>"> <xsl:text>|</xsl:text> <xsl:if test="@n"> <xsl:value-of select="@n"></xsl:value-of> </xsl:if> </xsl:template> instead of: <xsl:template match="t:milestone<span>[klzzwxh:0001='block'...
There are for sure some fixes to be made, especially to tighten the alignment between schema and stylesheets, and correct some minor bugs. I think the default behaviour should not produce a linebreak in html as stated by Scott Di Giulio. I would suggest replicating the behaviour that is implemented in the more specific stylesheet (teimilestone.xsl) that applies when @unit is 'fragment' or 'block'. Code to replace the code showed above (br element + @rend) <xsl:otherwise> <!-- adds pipe for block,...
https://www.stoa.org/epidoc/gl/latest/trans-diplomatic.html –> "see also" link missing https://www.stoa.org/epidoc/gl/latest/trans-textpart.html –> 3rd §: formatting pb 'with an type="textpart".' https://www.stoa.org/epidoc/gl/latest/trans-textpart.html –> "according to london: Section A": transformed html missing for second and third example block. https://www.stoa.org/epidoc/gl/latest/trans-linebreak.html -> to show the effect of a line break, the example shoud provide at least 2 lines (otherwise...
https://www.stoa.org/epidoc/gl/latest/trans-diplomatic.html –> "see also" link missing https://www.stoa.org/epidoc/gl/latest/trans-textpart.html –> 3rd §: formatting pb 'with an type="textpart".' https://www.stoa.org/epidoc/gl/latest/trans-textpart.html –> "according to london: Section A": transformed html missing for second and third example block. https://www.stoa.org/epidoc/gl/latest/trans-linebreak.html -> to show the effect of a line break, the example shoud provide at least 2 lines (otherwise...
Seems very fine to me. Maybe some info about what impact for the parameter on in the first example from GvCyr007 to be completely explicit.
I agree that the first part of the text, seems related to an "era" where people had to understand the limitations of tradictional typographic conventions. I think last two section are still relevant for giving context about the EpiDoc endeavour. I would consider just keeping these two, plus deleting or updating the list of project example projects at the end. Some info about EDAG, the fact that releases are regularly offered, the markup list and all the community work could be added there... plus...
Stylesheets: @xml:lang on div[type='textpart'] not handled
I put it on 9.1 but I'm not sure it was the right thing to do... shall I close it or will it be done automatically with the release?
Stylesheets: @xml:lang on div[type='textpart'] not handled
You're right: the pull request was merged on 21 of August. See https://github.com/EpiDoc/Stylesheets/pull/1
added pull request to github https://github.com/EpiDoc/Stylesheets/pull/1 The modification just adds a call to the templateattr-lang that takes theab/@xml:lang and transfers it to the html div[@class='texpart']. The stylesheet doesn't take into account any attribute on div[@type='texpart']. I hadn't got at first that the GL says that there is only one ab per div. <!-- a div[@type='textpart'] is created for each ab element, independant of the textpart / ab hierarchical structure --> <xsl:if test="@xml:lang">...
The test suite uses some html resulting files for the comparison. So each new developement in the XSLT resulting in changes in the html shoud be updated. * Idea from Gabby (2019-01-30), email conversation with J. Nourish and EMo : rather than a bunch of random and hopefully representative EpiDoc files, we should hand-curate one or a small number of artificial files that exemplify all of the features we want to test against regression for (things like square brackets handling are the potentially most...
Yes, it seems a good start. As far as I understand it, the test operates on the full html output for the following edition structure mentionned in the test as a string straight string comparison. Currenttly the structures given in the script are : ('default', 'dol', 'edak', 'inslib', 'iospe', 'sigidoc', 'spes'). If I get it right, the result will also depend on the leiden-style and other parameters that are chosen in the xml parameters file. Should the test be enhanced with all the possible parameters...
Yes Gabby, I'd be glad to do it. Concerning the testing for nun-regression against other work, I might take advantage of some guidance (I don't have as many different XML EpiDoc datasets in my work). What would you advice?
Stylesheets: @xml:lang on div[type='textpart'] not handled
Document structured bibliography in GL
I wouldn't mind having these suggested values added to the schema, but on the other hand, I think it is ok to leave it open.
Ok I agree. Message sent: http://lsv.uky.edu/scripts/wa.exe?A2=ind1712&L=markup&F=&S=&X=2599D03FEA67FE8470&Y=emmanuelle.morlock%40mom.fr&P=48
I went through the markup list archive of Novembre 2014 when that bibliography topic was discussed. It seems that "genetic" relations between bibliographic references can be expressed in 2 ways: 1. by classifying the references in categories ('primary', 'secondary', 'derived', principalEdition', 'translations', etc.) 2. by indicating, at the bibliographic item level (<bibl>), the source it is based on, wether an autopsy of the text bearing object or another edition. In case 1. the genetic relation...
I went through the markup list archive of Novembre 2014 when that bibliography topic was discussed. It seems that "genetic" relations between bibliographic references can be expressed in 2 ways: 1. by classifying the references in categories ('primary', 'secondary', 'derived', principalEdition', 'translations', etc.) 2. by indicating, at the bibliographic item level (<bibl>), the source it is based on, wether an autopsy of the text bearing object or another edition. In case 1. the genetic relation...
corrected typo
typo correction
As the project the question came from chose some more intuitive solution, the interest lowered. A straightforward solution for producing an output with different kind of brackets was used in the end : <seg type="graphemic|phonemic|phonetic">) that would produced different brackets in the rendering after transformation). As it is output oriented, it not of much help here. I went through the discussions on encows (https://groups.google.com/forum/#!topic/encows/emN7ZDEnlwY) and markup, and found no...
Document: use 'c' for illegible characters that are known to be vowel/consonant/etc.
Testing procedure for changes in the XSLT stylesheets
Re-engineer guidelines process to use tunnel parameters for examples
Thanks Tom, it tested it with oxygen and the new values were not presented., Even after updating the oxygen tei framework. Sorry for the bothering ticket : I should have checked the GL first! I went to GitHub looking for the source spec or ODD… In https://github.com/TEIC/TEI/blob/dev/P5/Source/Specs/att.citing.xml found my answer (but with some kind of inversion I guess. So maybe all that was not completely unuseful… <valItem ident="column"> the element identifies an entry number or label in a list...
"entry" should be added too (for dictionnary/encyclopedia entries, often ordered alphabetically so with no page number or item number)
GL: broken link to an XSL
Document: use 'c' for illegible characters that are known to be vowel/consonant/etc.
Re-engineer guidelines process to use tunnel parameters for examples
Document structured bibliography in GL
The correct link to Markup might be: https://lsv.uky.edu/scripts/wa.exe?A2=ind16...
fixing the footer by replacing the navigation X...
Document: use 'c' for illegible characters that are known to be vowel/consonant/etc.
Document: use 'c' for illegible characters that are known to be vowel/consonant/etc.
Testing procedure for changes in the XSLT stylesheets
Testing procedure for changes in the XSLT stylesheets
Having to customize the example stylesheet for the Karnak Cachette project, I will...
Testing procedure for changes in the XSLT stylesheets
Document structured bibliography in GL
Document structured bibliography in GL
ok
Guidelines : exemple for the use on @source should be of type datapointer
That's true that the use of an attribute is the simpliest way of having a set of...
Agree too. Would this be compatible with having also an internal apparatus ? think...