TEIC
Can't change common parameter default value
good morning,
In the stylesheet common/common_param.xsl, I struggle to understand the relations between the parameters and the tei elements they refer to.
When generating HTML documentation from an ODD, I get the default value "(unknown project)" in <h2 class="institution"/> and can't find which element to edit so that its value is put here.
<div class="stdheader autogenerated"><h2 class="institution">(unknown project)</h2><h1 lang="en" class="maintitle">...</h1></div>
Maybe the document of common_param.xsl should contain what is the element concerned when relevant, or at least the parameter institution should have an empty string as default value.
Best Charles
This and other stylesheet parameters/variables are documented at http://www.tei-c.org/release/doc/tei-xsl/
Ok my bad, I didn’t search enough. However, i find it unfortunate that parameters default values overtake valid TEI elements that could do the same job
Le 28 mars 2017 à 12:36, Lou [email protected] a écrit :
This and other stylesheet parameters/variables are documented at http://www.tei-c.org/release/doc/tei-xsl/ http://www.tei-c.org/release/doc/tei-xsl/ — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/TEIC/Stylesheets/issues/253#issuecomment-289730239, or mute the thread https://github.com/notifications/unsubscribe-auth/APGLHanSgo6z2hESWO8OG--ToX5h-BzNks5rqOKfgaJpZM4MrOfP.
Charles Riondet [email protected] Inria (ALMAnaCH)
This one in particular is a puzzle to me and I've tended to just get rid of it when building local documentation. I think we should change it unless @lb42 knows of good reasons why not.
Sorry if I missed something, but what is the complaint here? What are the "valid TEI elements that could do the same job" ? And what's puzzling about having a default value for one of the headings on a generated HTML web page?
In this particular example, I think the $institution parameter could be replaced by, for instance,
Le 28 mars 2017 à 16:00, Lou [email protected] a écrit :
Sorry if I missed something, but what is the complaint here? What are the "valid TEI elements that could do the same job" ? And what's puzzling about having a default value for one of the headings on a generated HTML web page?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/TEIC/Stylesheets/issues/253#issuecomment-289778892, or mute the thread https://github.com/notifications/unsubscribe-auth/APGLHZcBkDHznDTHJf6b42hDWN0H09H2ks5rqRJmgaJpZM4MrOfP.
Charles Riondet [email protected] Inria (ALMAnaCH)
Thanks for the explanation! You could certainly customise the stylesheet t do that. But the <publisher> might not be supplied (it's not mandatory) so you'd still need to have a default value of some sort wouldn't you?
I could certainly customise the stylesheet, and probably will do that. Though, I'm not so sure a default value is needed here, in particular a "negative" one. I understand default values for generated HTML when it's extra content, like "Home" for the link to the home page, but here the default value doesn't add much, except for me a feeling of failure :-)
The complaint is that the ODD to HTML conversion bungs "(unknown project)" at the top of your documentation unless you find the right parameter and kill it. I'm sure it's there for a reason, but not an obvious one. I don't think that should be the default.
+1 for @hcayless comment of Mar 28. One might use the same stylesheet (e.g., generate HTML documentation from an ODD) for multiple projects. Defaulting to a value that is pulled from the header of the ODD is more flexible than defaulting to "(unknown project)", which is highly unlikely to be what the user (or, at least, this user) would want to see even if the project is unknown. Specifying a value as a parameter makes the value part of the transformation process, rather than part of the project to which the ODD belongs.
"Defaulting to a value that is pulled from the header" is tricky, because Lou's point here is "what if you fail to supply the value (or mark it up properly) -- wouldn't you need a default value then?". This issue is about two things, it seems to me:
- locating a value in the TEI header for the project name (that should be easy)
- coming up with a non-negative default for the stylesheet, because you need that default anyway
This is an inquiry, and not an argument: Why is a negative value worse than "(unknown project)"? That is, why shouldn't the default, in the absence of the necessary information within the ODD, be to omit the <h2>, or emit an empty one?
I think the inquiry is well-placed, as long as the stylesheet provides an option to pull values straight from the header. Indeed, in such cases one might argue that the current default is OK. Good point.
Good. Could we agree on an element from the header from which to pull the value if it exists? Would <funder> be OK?
@laurentromary I doubt people will be likely to fill out <funder> any more than they were whatever else is providing the institutional info. It seems to me the “unknown project” output is an outright error. The default language and its prominent position in the output documentation makes it look like the title of the project, not the funding institution, though the class="institution" on the output <h2> suggests that the intention is to output some responsible institution. Some projects may be organized by multiple institutions or no institution at all, and the assumptions implicit in these lines of XSLT seem pretty problematic. (Why say a project is “unknown” if no one filled out a sponsoring or publishing institution in the header?) If we are going to pull from a header element at all, it should be the titleStmt/title shouldn’t it? That is, if we want something to identify the project at the top of the output HTML documentation, shouldn’t it simply be the title of the project?
If we are going to pull values from the header, perhaps we ought to review which should be the top priority, and whether we require default outputs at all for missing content.
@laurentromary @ebeshero As I wrote earlier, and as Elisa just endorsed, "unknown project ... is highly unlikely to be what the user (or, at least, this user) would want to see even if the project is unknown". Perhaps we should separate the following details:
- What should happen if the user declines to specify a project value (whether as an element in the ODD or as a parameter during the transformation)? I think that outputting "unknown project" is the wrong answer because nobody wants to see this in output. I think the right answer is"nothing; that's up to the user". (If we pull from something known to be in the ODD, such as a title, it won't be omitted in any case.)
- If the user wishes to specify a project value, where should it be specified? I think that requiring it only as a stylesheet parameter is the wrong answer because, as I wrote earlier, that makes it a feature of the transformation, and not of the ODD. Allowing a value in the ODD to be overwritten by a stylesheet parameter may or may not be desirable; I can't imagine using it, but users who don't need it don't have to think about it, so it does no harm.
- If a project value should be specified in the ODD, where should it be specified? I agree with Elisa's observations here: the funder carries less information value with respect to the ODD than the title of the project. Indeed, the current "unknown project" default suggests that it's supposed to be an identifier of the project, and not of the funder of the project.
@ebeshero
If we are going to pull values from the header, perhaps we ought to review which should be the top priority, and whether we require default outputs at all for missing content.
One consideration might be that outputting "unknown project" looks like the result of writing an error message into the output. If failing to specify the project is considered a mistake, we could raise a warning during transformation. If we want to output a default value if the user doesn't specify otherwise, something like "Customization of TEI P5 version ..." looks more like something a user might want to see in documentation than "unknown project".
I like @djbpitt 's suggestion. Then we have to possibility to have a useful uniform presentation for "neutral projects" and (if well documented) allow one to duplicate the transformation scenario and pass something more specific.
So far I agree completely with @djbpitt. To go a bit further though, while I agree that specifying such output text only as a stylesheet parameter is undesirable, I do like the idea of being able to override the various output values (like project name and home page, etc.) from a stylesheet parameter.
At the moment I can’t think of anyplace better than @ebeshero’s suggestion of /TEI/teiHeader/fileDesc/titleStmt/title, except that answering the question “which one?” is not trivial.
Here’s a modification of a tei:title -> dc:title routine I wrote years ago:
<xsl:template name="get-title">
<xsl:for-each select="/TEI/teiHeader/fileDesc/titleStmt[1]">
<xsl:variable name="got-title">
<xsl:choose>
<!-- if there's a short or main title, take it -->
<xsl:when test="title[ @type = ('short','main','preferred','marc245a')]">
<xsl:apply-templates select="(
title[@type eq 'short'][1],
title[@type eq 'main'][1],
title[@type eq 'preferred'][1],
title[@type eq 'marc245a'][1]
)[1]"/>
</xsl:when>
<!-- if not, just take the 1st <title>, and issue a warning if there were more -->
<xsl:otherwise>
<xsl:if test="count( title ) gt 1">
<xsl:message>WARNING: using first title</xsl:message>
</xsl:if>
<xsl:apply-templates select="title[1]"/>
</xsl:otherwise>
</xsl:choose>
</xsl:variable>
<xsl:if test="count( ../titleStmt ) gt 1">
<xsl:message>WARNING: only 1st ‹titleStmt› examined</xsl:message>
</xsl:if>
<xsl:if test="$got-title">
<dc:title><xsl:value-of select="$got-title"/></dc:title>
</xsl:if>
</xsl:for-each>
</xsl:template>
All that said, where does “(unknown project)” appear in the output? I don’t see it in mine.
@sydb It has shown up at the top of the generated HTML output of just about every ODD I've made...
@sydb and all: Here's a simple example from one of my students' projects:
input ODD: https://github.com/ahunker/Hamilton-Project/blob/master/ODD/hamiltonODD.odd
Here, I notice we've used the titleStmt/title, and it's being output, so we don't really need to add anything here. I think we just need to get rid of the default "unknown project" that persistently haunts and irritates us.
Interesting. I vaguely remember that in the output, but it’s not there now. I wonder what I did to get rid of it. What process are you (@ebeshero and @charlesriondet) using to generate HTML output from ODD input? Being the old codger I am, I was using commandline roma. To be precise:
| $ /usr/share/tei-roma/roma2.sh --patternprefix=mm_ --xsl=/home/syd/Documents/Stylesheets --noxsd --nodtd --dochtml --localsource=/home/syd/Documents/TEI_dev/P5/p5.xml --isoschematron ./INPUT.odd .
Where ~/Documents/Stylesheets/ refers to the dev branch (as does ~/Documents/TEI_dev/, of course).
I see the same output as Elisa. I generate the HTML documentation using the transformation scenario inside <oXygen/> (without setting any parameters).
Thanks, @djbpitt. I get the same result as you (“(unknown project)” at the top) when using <oXygen/>. It also does not have the author name bunged up against the title in the <title> and <h1>. Quite different. Interesting.
@sydb Are we to understand that command line roma is compiling an alternative stylesheet than the <oXygen/> process?
Yes, either that or it has parameters set differently. (Although “compile” is not the right word: “execute”, “run”, “use”, or perhaps even “perform”, but I don’t like that last one.)
To be precise, my roma is using /home/syd/Documents/Stylesheets/odds/odd2odd.xsl and its friends, i.e. the development stylesheets direct from GitHub. My <oXygen/> is running whatever comes with the TEI framework I installed. But I don’t remember if that’s our released framework or the bleeding-edge framework, and don’t know how to tell the difference.
There seems to be some confusion here about the relative roles of the header and the stylesheet parameters. The OP complained that it wasn't clear where the default value for a stylesheet parameter was coming from, nor how to set it. That's fair enough and probably we could do more to explain how to set parameters for the stylesheets, and why this is a good idea (it's actually pretty easy in oXygen, but not everyone uses oXygen). The discussion about what the default value for an unset parameter should be seems to have gone off completely at a tangent. We don't expect the header to control the values of any other stylesheet parameters (well, maybe if you have an ODD in your header, and processing models therein) so it seems to me that the only point at issue is whether or not this particular parameter should have a default value or not. My guess is that Sebastian gave it one so that you'd notice if you hadn't set it, because your HTML layout would look weird with nothing as a header. But the stylesheet library could certainly be tweaked to say nothing at all, or "Project Unspecified" or the first three words of the second <title> in a <titleStmt> if there is one.
And since most users will not necessarily set this parameter, I was supporting the idea from @djbpitt to have something like "A TEI application" as a default so that it is not bothersome to have it if nothing more is done.
While @lb42 is technically correct, the OP was asking about where to find and set the default value of a parameter, I think it is quite reasonable to use this question as a gateway to improving the situation.
We don't expect the header to control the values of any other stylesheet parameters
Well, no. While this is true of many parameters that control formatting (like $collapse_lines), I expect most metadata to be extracted from the TEI header if possible, and a parameter to exist to override that. A default value to be used if extraction fails and no parameter is set is also, of course, a good idea.
This means, thought, that you can’t just have the default value to be used be the default value of the parameter. (Which is how it is mostly done now.) You either need to have slightly complex code:
IF (user set param) THEN use it
ELSE IF (I can find the right snippet of metadata in TEI header) THEN use that
ELSE use the default string
Or you may be able to bung it all into the setting of the parameter:
<xsl:param name="simpleExample" select="( /complex/XPath/that/gets/right/title, 'default' )[1]"/>
or
<xsl:param name="complexExample">
<xsl:choose>
<xsl:when test="simple/path/one">
<xsl:value-of select="simple/path/one"/>
</xsl:when>
<xsl:when test="demo:intricateTest2()">
<xsl:copy-of select="funny/other/thing"/>
</xsl:when>
<xsl:when test="moderate/XPath eq pression">
<xsl:sequence select="useful/thing/here"/>
</xsl:when>
<xsl:otherwise>
<xsl:text>A TEI Application</xsl:text>
</xsl:otherwise>
</xsl:choose>
</xsl:param>
Stylesheets group fix #1: make fo_textstructure.xsl behave like html_textstructure.xsl, and not output anything if $institution is an empty string, in commit 85480f3.
