#553 JTEI schematron validation issues
- I am mystified by this schematron error message:
E [ISO Schematron] Tag delimiters are not allowed for tag: they are completed at processing time via XSLT.
It relates to the following bit of text:
A <tag>milestone unit=’serialPart’ n=’12’/</tag> can be used
Changing the entity references into real quotes doesn't seem to affect the issue.
- I am infuriated (well, a bit peeved) by the following schematron message:
"Please refer to the exact version of the TEI Guidelines, and link to the version that can be found in the Vault section. For an overview of all archived versions, see http://www.tei-c.org/Vault/P5/. If you're referring to the English version, the correct URL will likely take the form of http://www.tei-c.org/Vault/P5/{$version-number}/doc/tei-p5-doc/en/html/."
But I don't want to refer to a specific version. I want to refer generically to the Guidelines, whichever version is current. (and "the form of" should in any case read "the form" -- I say nothing of the markedly North American use of "likely")
- I am also mildly annoyed by the insistance that I specify pixel dimensions -- both height and width -- for all my graphics. Firstly I don't see why I need to specify both, on the assumption that I don't want the images to be distorted. Secondly, if this is meant to specify the actual (source) size of the graphic, why is it necessary at all? Thirdly, if it is not the actual (source) size, why not permit one to specify this as a percentage of the target output medium?
Discussion
Diff:
Number 1 looks like a bug. Will investigate.
Number 2 is what JTEI wants. Any reference to "the Guidelines" generically is going to be overtaken by future changes; any statement you make about the Guidelines can only really refer to a single version of it. Even referring to a chapter number might be a risk because a new chapter might be added at some point, changing the chapter numbers.
Number 3 is helpful for processing into ODT and PDF, where decisions have to be made about how best to fit the graphic onto the page. If you look at lines 675ff in [Stylesheets]/profiles/jtei/odt_common.xsl, you'll see how that works. We did quite a lot of experimentation to figure out the optimal way to do this.
Last edit: Martin Holmes 2015-05-05
Number 1 appears to be triggered by the closing slash for the self-closing tag. That is a bug, I think; I've submitted a fix in rev 13208, which should eventually find its way through to the bleeding-edge edition of the Oxygen plugin, so if you're subscribed to that, you should be able to see if the fix worked after updating your plugin.
Last edit: Martin Holmes 2015-05-05
Thanks for the quick response Martin. On (2) I really don't think your argument holds water. In a phrase like "The chapter in the P5 Guidelines which discusses the header is always going to be useful to librarians" clearly I am not referring to any particular version of P5, so why should I have to specify one?
And I wasn't proposing to refer to chapter numbers, but to use the "current version" URL. On (3) I think you've may have optimised for the processor rather than the author. In practice, I went through and added exactly the same dimensions for all my graphics (all of which are different sizes) and lo, they all came out looking fine (though not identically sized) in the PDF.
On number 2: If you want to link to a specific chapter with a URL, then you most definitely are referring to a specific edition; there's no guarantee that chapter will continue to exist, or that its successor if there is one will share the same file name.
On number 3: try the ODT output; that's where I think we're doing most of that calculation. But I would always say it's good practice to provide image dimensions; if you're generating HTML, it helps the page layout engine render pages faster.
On number 1, I realized over breakfast that it could perfectly well be the error message that's wrong rather than the regex, so I need to look again there. Unfortunately my Jenkins box went down this morning and I don't have a clue why; and I have to go off for an appointment very shortly. I might need to reverse the change I made before and clarify the error message.
Indeed on number 1, the error is in the error message and in the associated XSLT. Working on it...
I've clarified the error message to say that closing slashes shouldn't be included. What you'd need to do is:
The JTEI documentation does say that IIRC, but we probably should make the schema and possibly the Schematron more helpful.
Ah, I had not noticed that use of @type in the doc. I've changed them to
<code><milestone /></code>vel sim now.
Last edit: Lou Burnard 2015-05-05
I too am a bit puzzled by the insistence on supplying the graphic width and height. Why not read those from the file itself?
It's mildly depressing to see work like this (graphics handling) duplicated between jTEI and the rest of the Stylesheets.
Is there a way to read image dimensions in XSLT?
I don't think it's reasonable to assume that we'll want to do the same thing with graphics as the rest of the Stylesheets do. We have output targets which are specific to the journal and its purposes, such as OpenEdition XML, and our ODT output which is structured to meet the goals of reviewers and editors.
On 5 May 2015, at 18:22, Martin Holmes martindholmes@users.sf.netamp#109;amp#97;amp#114;amp#116;amp#105;amp#110;amp#100;amp#104;amp#111;amp#108;amp#109;amp#101;amp#115;amp#64;amp#117;amp#115;amp#101;amp#114;amp#115;amp#46;amp#115;amp#102;amp#46;amp#110;amp#101;amp#116; wrote:
Is there a way to read image dimensions in XSLT?
No, but why are you tied to XSLT? The main odt and docx generation implements it by generating a second XML file with data in which XSLT can read
I don't think it's reasonable to assume that we'll want to do the same thing with graphics as the rest of the Stylesheets do.
Really? That's a bit weird, as it implies you use the same tagging in a different way
We have output targets which are specific to the journal and its purposes, such as OpenEdition XML, and our ODT output which is structured to meet the goals of reviewers and editors
Of course, but I don't see the relevance of that to the mechanics for processing graphics files
Sebastian
If you look at lines 675ff in [Stylesheets]/profiles/jtei/odt_common.xsl, you'll see what we're doing with graphics rendering in the ODT output. If the standard Stylesheets code will do exactly that, then we'll happily use it. Remember we originally wrote all this stuff as a separate project, with no expectation of merging it into the Stylesheets; Council asked us to do that. I'm sure there will be other areas where we can piggy-back on existing code too.
Council discussion 2015-05-28: #1 and #2 solved; mild recommendation that #3 be a warning rather than an assertion.
Closed-fixed per Council decision 2015-05-29.