This is great timing. While we will be looking to review and provide feedback, I have an initial comment/query. We have been working on providing transcripts and we use Publishing tagset (1.2). Your descriptions states: “The following recommendation is for JATS v 1.3 and backward. Differences between the Journal Publishing and Archiving DTDs are noted within the recommendations as applicable.”, but looking at your solution (example 5) it only supports 1.3 as earlier versions of the tagset do not allow <xref> in <media> .
Can you suggest a way that 1.2 users can capture transcripts in a separate or and link to a element? Because of these limitations to link out to other element/object within this file, we had been toying with using etc. which is not ideal, but were out of ideas. Can you please confirm that your recommendation for Transcript mark up is only 1.3 (blue) compliant ?
we had been toying with using <textual-form specific-use="transcript"><named-content content-type="speech"><speech> etc which is not ideal, but were out of ideas.
melissah76
Comment from user:
will provide a brief overview of an issue that I have raised previously in the Github repository (see issue #34 and as well as a comment within this pull request).
The application of these recommendations in the validator through schematron generates some errors and warnings related to <uri> element. I believe that this application goes too far in relation to the goal of the accessibility recommendations have. In particular, accessibility recommendation number 13 (related tu <uri> and <self-uri>) requires <uri> elements to have descriptive content, but in the “Tag Library” of this element it is recommended that the url be placed as content (see “Usage/Remarks” and “Tagged Samples”). Currently schematron requires the @xlink:title attribute on all <uri>, even if the @xlink:href attribute is not present (which is not recommended).
Furthermore, in the case of a reference listing, many elements use the <uri> field as a substitute for the DOI (when it is not available), so only an url can go inside this field (what else can an uri field be inside a reference element other than a link to the referenced resources?). Also, it is redundant to add an @xlink:title attribute, sicen the description is given by the context (it is an uri that belongs to a reference within a list of references). If you look at the examples of the <uri> element, most of the use cases for this element are similar to the one above, as this tag is predominantly used in <front> and <back> within a context of use that gives it meaning. Links to external elements within the body use the <ext-link> tag, where these recommendations may make some sense for accessibility (but not within <self-uri> or <uri>).
Comment from user:
This is great timing. While we will be looking to review and provide feedback, I have an initial comment/query. We have been working on providing transcripts and we use Publishing tagset (1.2). Your descriptions states: “The following recommendation is for JATS v 1.3 and backward. Differences between the Journal Publishing and Archiving DTDs are noted within the recommendations as applicable.”, but looking at your solution (example 5) it only supports 1.3 as earlier versions of the tagset do not allow
<xref>in<media>.Can you suggest a way that 1.2 users can capture transcripts in a separate or and link to a element? Because of these limitations to link out to other element/object within this file, we had been toying with using etc. which is not ideal, but were out of ideas. Can you please confirm that your recommendation for Transcript mark up is only 1.3 (blue) compliant ?
we had been toying with using
<textual-form specific-use="transcript"><named-content content-type="speech"><speech>etc which is not ideal, but were out of ideas.Comment from user:
will provide a brief overview of an issue that I have raised previously in the Github repository (see issue #34 and as well as a comment within this pull request).
The application of these recommendations in the validator through schematron generates some errors and warnings related to
<uri>element. I believe that this application goes too far in relation to the goal of the accessibility recommendations have. In particular, accessibility recommendation number 13 (related tu<uri>and<self-uri>) requires<uri>elements to have descriptive content, but in the “Tag Library” of this element it is recommended that the url be placed as content (see “Usage/Remarks” and “Tagged Samples”). Currently schematron requires the @xlink:title attribute on all<uri>, even if the @xlink:href attribute is not present (which is not recommended).Furthermore, in the case of a reference listing, many elements use the
<uri>field as a substitute for the DOI (when it is not available), so only an url can go inside this field (what else can an uri field be inside a reference element other than a link to the referenced resources?). Also, it is redundant to add an @xlink:title attribute, sicen the description is given by the context (it is an uri that belongs to a reference within a list of references). If you look at the examples of the<uri>element, most of the use cases for this element are similar to the one above, as this tag is predominantly used in<front>and<back>within a context of use that gives it meaning. Links to external elements within the body use the<ext-link>tag, where these recommendations may make some sense for accessibility (but not within<self-uri>or<uri>).