| 2023-11-21 19:38:50 |
Mackenzie Johnson |
description |
EG 3.8.0
PostgreSQL 10.something?
Okay, these issues stretch all the way back to the official .xsl file hosted on the MADS website, so it's not something that popped up as part of any direct EG developement. I suspect the XSLT for XML 1.0 is not getting much or any focus from LoC anymore.
First, a question: is there a reason why the contents of MARC21slimUtils.xsl is copied into the MARCtoMADS XSLT instead of being called in the schema? Does it have something to do with MARC21slimUtils.xsl not being part of the .xsl files included in the main branch of the repository (as far as I could see)?
Second, the XML 1.0 version of the XSLT that we use technically still calls to the MADS 2.0 schema in the mads:madsCollection node rather than MADS 2.1. The mads:RecordOrigin node also still says the XSLT is on revision 2.13 when the last official revision was 2.15.
Third, past fixes in the Geographic templates have actually broken other components of the Geographic subject crosswalk -- namely, the XSLT as it currently stands does not transform any 451$a or 751$a values, as an xsl:otherwise node that would cover both those fields (and acts similarly in comparable templates) has been commented out in an older revision, and the template call for the 751 field is also matching on the $z subfield instead of $a (the 781 field for linking geographic subdivisions does still match on $z).
Fourth, related to updating the schema to 2.1, a template could be made to parse out an X00$q value (the fuller form of a personal name) to become a distinct namePart node with a fullerForm attribute. Currently the $q is translated into MADS, but I believe it stays with the $a subfield
A mix of small but significant changes, small and less significant changes, and if there is a desire to fully make use of MADS 2.1 instead of MADS 2.0, the possibility to add a new small template. I've made a number of those fixes in a local copy, but again I figured I should create the bug before I share that (though I'll gladly attach it upon request). |
EG 3.8.0
PostgreSQL 10.something?
Okay, these issues stretch all the way back to the official .xsl file hosted on the MADS website, so it's not something that popped up as part of any direct EG developement. I suspect the XSLT for XML 1.0 is not getting much or any focus from LoC anymore.
First, a question: is there a reason why the contents of MARC21slimUtils.xsl is copied into the MARCtoMADS XSLT instead of being called in the schema? Does it have something to do with MARC21slimUtils.xsl not being part of the .xsl files included in the main branch of the repository (as far as I could see)?
Second, the XML 1.0 version of the XSLT that we use technically still calls to the MADS 2.0 schema in the mads:madsCollection node rather than MADS 2.1. The mads:RecordOrigin node also still says the XSLT is on revision 2.13 when the last official revision was 2.15.
Third, past fixes in the Geographic templates have actually broken other components of the Geographic subject crosswalk -- namely, the XSLT as it currently stands does not transform any 451$a or 751$a values, as an xsl:otherwise node that would cover both those fields (and acts similarly in comparable templates) has been commented out in an older revision, and the template call for the 751 field is also matching on the $z subfield instead of $a (the 781 field for linking geographic subdivisions does still match on $z).
Fourth, related to updating the schema to 2.1, a template could be made to parse out an X00$q value (the fuller form of a personal name) to become a distinct namePart node with a fullerForm attribute. Currently the $q is translated into MADS, but I believe it stays with the $a subfield
A mix of small but significant changes, small and less significant changes, and if there is a desire to fully make use of MADS 2.1 instead of MADS 2.0, the possibility to add a new small template. I've made a number of those fixes in a local copy, but again I figured I should create the bug before I share that (though I'll gladly attach it upon request).
Update (2023-11-21): Found more issues! Templates are also not properly applied across subfields in 450 and 550 fields. |
|
