Open bezverec opened 1 year ago
S úrovní validace v ProArcu spokojeni úplně nejsme. Je možné, že v novém releasu se to chová zase jinak a lépe (aktualizace neprovádíme ihned).
Zeptám se k tomu ProArcu - můžete to trochu upřesnit, co nefunguje, nebo jaké další kontroly byste uvítali?
Možná to vyznělo přísněji, než jsem to myslel. Dodávám, že nemáme nasazené nové rozhraní. Je možné, že se tyhle věcí řeší, nebo jsou ve skutečnosti dávno vyřešené. Něco z toho si z issues na GitHubu nebo sdílení zkušeností kolegů z MZK vybavuji. Budeme samozřejmě rádi, pokud ProArc jen používáme jiným než zamýšleným způsobem, pokud se chová občas divně jen naše instance, nebo pokud máme jen někde špatná nastavení :)
"Hodně" třeba řešíme překlepy a chyby v datech vydání u výtisků periodik. Tam ProArc není dostatečně restriktivní. Projdou třeba i mezery za tečkou nebo pomlčkou. Podobný případ jako dateIssued by mohlo být i partNumber. Tohle by třeba lépe vyřešit šlo, nevím.
Potom se nám třeba při exportu periodik hodně stává, že ProArc nedokáže dostatečně informovat o prázdném "adresáři" NDK Číslo (model NDK Číslo bez stránek). Modelový příklad: NDK čísla se generovala hromadně, něco ale třeba nevyšlo, nebo vyšlo mimořádné číslo, změnila se posloupnost, prázdné NDK Číslo někdo zapomene smazat, exportované balíčky celého ročníku zmizí v průběhu exportu, jakmile to doje k prázdnému číslu, nebo zůstane jen prázdný log. Teď si nevybavuji, jestli rozhraní ProArcu vyplivne nějakou chybu. Většinou už sledujeme jen chování exportní složky. Při exportu většího množství balíčků nemá smysl čekat, operátor děla něco dalšího. Možnost sledovat někde stav exportu by se taky hodila.
Taky jsme řešili, že ProArc dokázal propsat znevalidněný identifkátor ISSN do MODS, ale v DC už atribut invalid chyběl.
Co má pak už jen menší souvislost, ale taky by se hodilo, je třeba možnost definovat exportní adresář. UUID je nepraktické, dochází ke zbytečným zmatkům při nějakých větších systematických exportech.
Taky jsme hodně zápasili s tím, pokud ProArc nedokázal informovat o nedostatku místa na úložišti při exportu.
Skutečnost, že se nám nikdy nepodařilo vyprodukovat balíček bez Warningů podle Komplexního validátoru, to bych asi na ProArc neházel, jsou to spíš nejasnosti na straně Validátoru. Myslím, že je ProArc snad i napřed.
Kdybych si na něco ještě vzpomněl, doplním.
Postupně to probereme... Co se týká chyb ve formátu dateissued u čísla per., to už se před časem v PA řešilo, díky za připomenutí. Nové issue (jako návrh na vývoj) k tomu je tady https://github.com/proarc/proarc-client/issues/378 - pokud to budete chtít ještě nějak doplnit nebo zpřesnit...
Co se týká toho prázdného čísla, tak tam by pomohlo nenechávat tu validaci až na export - a mohlo by to řešit tohle issue (zatím taky jako návrh na rozšíření) k validaci - https://github.com/proarc/proarc/issues/1532.
Pro pořádek, i když ji už asi všichni známe, přídávám odkaz na utilitku od Jana Bilwachse z NK. https://github.com/NLCR/visk7-nastroje
Pak mě samozřejmě zajímají další validační nástroje, pokud je někdo používá :) S úrovní validace v ProArcu spokojeni úplně nejsme. Je možné, že v novém releasu se to chová zase jinak a lépe (aktualizace neprovádíme ihned). Kontrola pak u nás probíhá klasicky ručně během zpracovávání, po importu do Kram., nebo přímo v balíčcích.
Můžete se podělit i pokud využíváte jiné nástroje na kontrolu obrazu aj.
Na prvním setkání Hradecký hranatý stůl padla zmínka o nějakém starším(?) validátoru, který to je? V LTP NKP mají nějakou vlastní doplňkovou utilitku na kontrolu PSP, ale zatím nebyla nikde prezentována.