Closed jbil7 closed 3 years ago
Od počátku bylo AIP XML tvořeno z části XSLT transformací a z části vložením systémových hodnot do pevně stanovených sekcí. Předpokládám že návrh umístění kam má ArclibXml generátor zapisovat systémové hodnoty byl tvořen na schůzích kde kolega Hochla spíše plnil požadavky řešitelského týmu. Nejsem si proto jist, zda by zpřehlednění "zapsat vše systémové do společného elementu" nebylo na úkor metodiky.
Také si nejsem jist zda je žádoucí aby byl formát AIP XML takto ovlivnitelný dodavatelem dat - AIP XML je uloženo v Archival Storage ale SIP profily nikoliv. Pokud se spoléháme na Archival Storage jako na možnost poslední záchrany, zdá se mi spíše vhodné mít některé jeho sekce (z velké části ty nad nimiž je následně vybudován vyhledávací formulář) pevně definované a mít i jednu pevně definovanou indexovací šablonu tak jak je to nyní. Váš návrh by zanesl vazbu mezi indexaci a SIP profily, při ztrátě SIP profilu by již nebylo možné AIP XML z Archival Storage plnohodnotně reindexovat.
K problématickým stavům na které jste narazil by docházet nemělo - nepřítomnost elementů do kterých jsou vkládány systémové hodnoty by měl systém v každém případě kontrolovat - toto je nutné doimplementovat.
V rámci #102 bylo implementováno přemístění problémových elementů do samostatné sekce, tedy k zmíněnému problému již nedochází.
Děkuji! Uzavírám společně s #102 .
V souvislosti s #102 bych rád otevřel diskusi také všeobecně o modelování arclibxml. V současné době je větší část arclibxml modelovaná XSLT šablonou v SIP profilu, jejž lze z pozice uživatele měnit. Menší část arclibxml (tj. například systémové hodnoty) je však dotvářená prostřednictvím fixních xpath výrazů v ArclibXmlGenerator.java. Jelikož se jedná o pevně definované cesty v kódu systému, není je možné z pozice uživatele měnit. Dle mého názoru může při této koncepci docházet k problematickým stavům při modelování SIP profilu; například při vynechání dmdSec pro Dublin Core dojde k chybě při ingestu, neboť xpath pro zápis verzování, jenž je natvrdo definován v kódu, není již validní. Má tato částečná nemožnost konfigurace modelu arclibxml v SIP profilu své opodstatnění?
S ohledem na výše popsanou věc souvisí i můj návrh k diskusi: Nebylo by možné, aby byly v rámci SIP profilu konfigurovatelné i systémové hodnoty (např. verzování, technická metadata)? Dokázal bych si to představit například tak, že ve Wiki projektu či v README by byly popsány systémové proměnné (pojmenovány např. dle sloupce G v tabulce https://docs.google.com/spreadsheets/d/1OR_NyrTfajZo5emu4PV2c0-pA3D6s2E6lcyx2cJXzLU/edit#gid=586517350). Tyto proměnné by bylo možné následně vyvolávat v XSLT šabloně na požadovaných místech. Je mi jasné, že modelování SIP profilu by mělo brát ohled i na následné mapování dotazů (nejen) v AIP search, které by nejspíše v důsledku také mělo být konfigurovatelné. Nemýlím-li se však, to již nyní splňuje
classpath:index/arclibXmlDefinition.csv
.Jsem si vědom toho, že by se jednalo patrně o dost rozsáhlý zásah do stávající podoby a nevím, do jaké míry by byl proveditelný. Úmyslem mého návrhu je především zpřehlednění SIP profilu, arclibxml a snad i pružnější konfigurace systému (např. kvůli budoucímu vývoji specifikací). Pokud by se ukázal jako neproveditelný, přimlouval bych se alespoň za jasnější vymezení, do kterých částí
ArclibXml generator
zasahuje a aby hodnoty z něj pocházející byly mapovány pokud možno pod jeden společný rodičovský element a nikoli roztroušeně po celém arclibxml jako nyní (jako je popsáno výše v souvislosti s verzováním).