Skip to main content
ExLibris
  • Subscribe by RSS
    • Back
    Aleph
    Ex Libris Knowledge Center

    How to eliminate unwanted spaces in 856 $$u added by p_course_01

    1. Last updated
    2. Save as PDF
    • Article Type: General
    • Product: Aleph
    • Product Version: 18.01

    Description:
    Our course reserves staff have recently come across what appears to be a problem with the p_course_01 process introducing spaces in 856 $$u contents. With this export process, it appears that ALEPH is inserting a space in the 856 subfield u value when a course's item has an 856 field that contains a domain name in it.

    Is this a known issue, and is this something that is going to be fixed? Or is this a configuration issue on our side?

    Example: One of our courses has an article with a URL, but in the XML file produced by the p_course_01 process, the URL comes out like this:

    <z13-user-defined-1>http://proxy.lib.univ.edu:2048/login?url=http://proquest.umi. com/abclink?did=12345678&sid=3&Fmt=3&clientId=12345&RQT=333&VName=QQQ</z13-user-defined-1>

    The space before "com" in this URL is not present in the original field entry (or in the OPAC).

    The process that we are running to generate the p_course_01 XML file is:
    /bin/csh -f p_course_01 ABC30,e-reserves.xml,COURSE-NUMBER,00,,Y,

    Resolution:
    The problem that you are seeing stems from a call to a routine called "fix_html_long_line". Its purpose is to cut up lines that would be too long to display well on a web page by inserting spaces into them at "appropriate" spots, such as after periods or semicolons. Clearly, this is not a good idea in this instance, where you have a URL to protect. However, there are few provisions that would allow you to keep them intact. The fix_html_long_line routine is run for every single line of XML input after all other translation (as in course-summary.trn and global.trn) is completed.

    I found only three exceptions. The first one is when the translate call comes from an X-Service call, which would not be the case in this situation. The second is when there are no lines at all in any .trn file. This is unrealistic, as there will always at least be lines in global.trn. The final exception is when an environment variable, "xml_translate" is set to "N". If this condition is met, no translation at all will be done on the XML, including the breaking of long lines. This also includes the application of translation rules from course-summary.trn and global.trn, however, meaning that the XML is not processed in any way. You currently have three fields that are being processed according to rules in course-summary.trn: due-date, z108-date-from, z108-date-to. These would not be transformed, and any fields that were using rules in global.trn would also not be transformed.

    So, the choice of how to proceed is yours. You could set the xml_translate environment variable before running the course-01 service in a couple of ways. You could edit the file $aleph_proc/p_course_01 and add a line to it before the call to pc_print_form:

    setenv xml_translate N

    If you run the service from the UNIX command line, you could simply set the variable before your run, then unset it after the run:

    setenv xml_translate N
    csh -f $aleph_proc/p_course_01 duk30...
    unsetenv xml_translate

    You would not want to have this variable set generally, as it would affect the output of all services and stop the transformation of any XML according to the configurations in .trn files.

    Of course you could settle for things as they are and live with the broken URLs in this output.

    • Article last edited: 10/8/2013