#183 Stylesheets default handling of tei:milestone not very useful

[BODARD Gabriel]

The EpiDoc Stylesheet htm-teimilestone.xsl (github.com) contains some detailed specialised cases for <milestone> in the 'ddbdp', 'dclp', and 'sammelbuch' Leiden-styles, but beyond this the default behaviour is less than useful, namely:

<xsl:otherwise>
  <br/>
  <xsl:value-of select="@rend"/>
</xsl:otherwise>

I think most people use milestones for (a) non-citation divisions of the text (e.g. objects intervening in the middle of a line, breaks between archaeological fragments of a surface), or (b) text divisions other than line, column, page, gathering for which there are "semantic sugar" elements. I'm not sure either of these—but certainly not the former—would want the behaviour above (especially since <milestone> requires @unit not @rend).

I would like to see:

1. some parametrised behaviour for projects that want one or other of the types of milestone (i.e. new-line or something like vertical-bar-in-text), and/or discrimination by attributes;
2. the default to be something less intrusive and scattershot than a newline and a (likely absent) attribute value.

If anyone objects to my inserting a default rendering such as abc|²abc or similar, then I propose at least to add a test for $leiden-style='london' to give this rendering, and we can survey for the needs of other projects to further improve and parametrise the stylesheets thereafter.

[Scott DiGiulio]

I'll send an email to Markup to survey the needs of the community; once we have a sense of what kinds of values would be desirable, we can come back around to implementing all of the relevant changes at one time (rather than ad hoc).

[Scott DiGiulio]

For the short term, will apply the provisional fix and will consider bigger picture changes in the future.

[BODARD Gabriel]

This was discussed briefly on Markup (last messaging, including thread), but I'm not sure what if anything has been implemented so far. Perhaps needs more discussion.

[BODARD Gabriel]

Emmanualle will summarise current XSLT behaviour, and propose an improvement. We will assess and comment on her improvement next month.

[Emmanuelle Morlock]

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, flanked by spaces if not within word -->
             <xsl:if test="not(ancestor::t:w)">
                <xsl:text> </xsl:text>
             </xsl:if>
             <xsl:text>|</xsl:text>
             <xsl:if test="not(ancestor::t:w)">
                <xsl:text> </xsl:text>
             </xsl:if>
</xsl:otherwise>

NB. in teimilestone.xsl the namespace prefix 't:' is missing before the tag 'w'.
A more refined enhancement could add the value undefined for @unit which is used in htm-teimilestone.xsl

[BODARD Gabriel]

Proposed solution is to have two default situations, and one special case:

1. If you have sections or blocks of text that need new lines and headings, and will have no overlappings words etc. across the blocks, then use <div type="textpart">
2. If you have semantic or physical breaks in your text that you want to record (perhaps with a pipe, superscript number, or similar), but (a) without a newline and (b) which might appear within words and/or across multiple epigraphic lines, then use <milestone unit="block|fragment|…"/>
3. Exception: if you have a break that you want to generate a new block and/or citation in the edition, e.g. column or section of text, but that might occur mid-word or otherwise cause overlapping hierarchies, then use <milestone rend="block"/> (with your choice of @unit as above.

The exact rendering of <milestone> in a particular instance will depend on a combination of project customisation, $leiden-style paramater, and @unit value, but EpiDoc default behaviour will probably be to use a pipe ('|'), possibly with the value of @n (if present) in superscript.

Does that seem to cover all the exceptions we have seen?

[Emmanuelle Morlock]

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']">
     <!-- adds pipe for block, flanked by spaces if not within word -->
      <xsl:if test="not(ancestor::t:w)">
         <xsl:text> </xsl:text>
      </xsl:if>
      <xsl:text>|</xsl:text>
      <xsl:if test="not(ancestor::t:w)">
         <xsl:text> </xsl:text>
      </xsl:if>
  </xsl:template>

htm-teimilestone.xsl

• Same as fragment or block

<xsl:otherwise>
             <!-- Default rendering: adds simple pipe (same as when @unit = 'fragment' or 'block' see teimilestone.xsl) -->
             <xsl:text>|</xsl:text>             
             <xsl:if test="@n">
                <sup><xsl:value-of select="@n"/></sup>
             </xsl:if>     
          </xsl:otherwise>

instead of:

 <xsl:otherwise>
             <br/>
             <xsl:value-of select="@rend"/>
          </xsl:otherwise>

txt-teimilestone.xsl

• ?????
• There is no <otherwise/> currently
• adding a defaut with pipe is easy, but I don't know if exposants can be produced automatically in XSLT... (Input from better developpers needed here!)

New question

The pipe ("|") represents a block boundary as a fragment boundary. Is it what we want? Are there conventions distinguishing between the two out there ? (eg. single pipe for fragment vs double pipe for block?

Next step
According to your answers, I will make changes in the XSLT and produce a pull request.

[Emmanuelle Morlock]

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.

[Emmanuelle Morlock]

merged today