Na czym tak naprawdę polega praca nad książką, która jest bazą danych?
Postaramy się dzisiaj przybliżyć proces przekształcenia bazy danych w standardzie XML do postaci książki w praktyce na przykładzie stosowanego przez nas systemu wydawniczego Arbortext. Pierwszym i kluczowym zagadnieniem, które będzie miało zasadniczy wpływ na wszystko, co będzie działo się dalej, jest zrozumienie różnicy między książką (w tym akurat przypadku zbiorem dowolnych haseł, np. encyklopedią) a bazą danych, z której ta encyklopedia pochodzi. W generalnym ujęciu, każde hasło będzie osobnym pudełkiem przechowującym treść w ustrukturyzowany sposób. Ze względu na konstrukcję i założenia baz danych ich administratorzy starają się jak najbardziej ujednolicić każde z pudełek. Powodów takiego stanu rzeczy jest kilka, ale przede wszystkim chodzi o dwa z nich:
- Unifikacja – im bardziej zunifikowana jest baza danych, tym łatwiej jest nią zarządzać i wykorzystywać. Gdyby przetworzenie bazy wymagało napisania osobnego warunku do każdej z pozycji, to korzystanie z niej byłoby kompletnie pozbawione sensu – równie dobrze można wtedy wszystko robić manualnie.
- Organizacja strumienia myśli twórców – baza danych działa jak wąskie gardło w procesie tworzenia treści, zmuszając autorów do myślenia i wprowadzania danych według jej struktury. Ta struktura ogranicza nie tylko zakres wprowadzanych danych, ale też np. ich kolejność, format czy długość.
Te kluczowe elementy sprawiają, że na wejściu baza danych jest maksymalnie zunifikowana, dzięki czemu jej właściciel może skutecznie, szybko i bezbłędnie tworzyć eksporty według wskazanych przez siebie warunków. Może to jednak powodować wiele problemów na etapie przygotowania treści takiej bazy danych do publikacji. Wszystko zależy od tego, jakie pytania potrafi zadać program, który ją będzie przetwarzać.
Praca w Arbortext
Z elementu źródłowego, jakim jest eksport z bazy danych lub inna forma XML, chcemy otrzymać efekt końcowy w postaci gotowej publikacji. W tym celu stosujemy ostylowanie, czyli zestaw warunków, które poszczególne informacje w kodzie źródłowym publikacji „tłumaczą” na ostylowanie. W najprostszym ujęciu taki warunek może brzmieć „jeśli dany fragment tekstu znajduje się w tagu <tytul>, to niech będzie wyśrodkowany i niech ma wielkość 12 punktów”. Tak proste warunki jest w stanie obsłużyć każdy program z Microsoft Wordem włącznie, ale baza danych wymaga z reguły o wiele bardziej skomplikowanego podejścia. W sytuacji, w której kończą się możliwości programu w zakresie zakładania warunków można albo zrezygnować z wizualizacji jakiegoś elementu, albo dodać go do pliku źródłowego.
Posłużymy się prostym przykładem z Wikipedii:
Końcowy efekt ma wyglądać następująco:
Definicja (z łac. definitio; od czas. definire: de + finire, „do końca, granicy”; od finis: granica, koniec)
Tag <head> został ostylowany boldem, następnie tag <lang> powinien zaczynać się od nawiasu i kończyć nim, jeśli po nim nie występuje tag <src>, a jeśli występuje, to zamknięciem nawiasu powinien się kończyć właśnie <src>. To typowy przykład warunków, które przekraczają możliwości przeciętnych programów do składu, ale nie sięgają nawet początku możliwości programów stworzonych do pracy z językami znakowanymi jak Arbortext.
W przypadku programów, które nie potrafią generować elementów, nawiasy trzeba dopisać ręcznie do pliku źródłowego, co nie oznacza jeszcze, że taki plik nie będzie nadawał się do zwrotu. Po pierwsze, trzeba jednak zachować odpowiednie procedury i środki ostrożności, a po drugie, nie każda taka zamiana będzie oczywista lub odwracalna. W programach, które potrafią generować tekst podczas renderowania poszczególnych stron przyszłej publikacji wygląda to następująco:
Dzięki temu można na bieżąco dodawać, dopisywać, przesuwać lub uzupełniać treść o elementy niezbędne wyłącznie dla danego typu publikacji na bieżąco bez martwienia się o zachowanie spójności pliku wejściowego. Pracując w Arbortext możemy dowolnie kształtować dodatkowe elementy zachowując tekst wejściowy nietknięty. W szczególnych przypadkach możemy automatycznie dogenerować do pliku wejściowego odpowiednio oznaczone tagi, które są następnie automatycznie usuwane po zakończeniu łamania za pomocą wbudowanych w program automatycznych skryptów.
O co można pytać?
Typowe pytania do struktury obejmują oczywiście tag, w którym dany element się znajduje. Do automatycznego łamania treści znakowanych potrzebna jest jednak jeszcze możliwość zadania co najmniej kilku dodatkowych pytań.
- Kim są twoi rodzice? – standardowe pytanie, które pozwala umiejscowić dany element w mapie i nadać mu styl w zależności od tego, w jakim tagu się znajduje. Dzięki temu tag <head> może inaczej stylować główkę hasła w zależności np. od tego, jaki to rodzaj hasła.
- Jakie masz atrybuty? – jednym z najlepszych sposobów ujednolicania bazy danych jest dodawanie atrybutów. Można je oczywiście całkowicie pominąć (i wiele programów do składu jest z takiego obrotu rzeczy bardzo rada) i zamiast np. <hasło typ=”sport”> znakować hasła według klucza <hasło_sport>.
- Który jesteś w kolejności w danym drzewie? – To pytanie pozwala znaleźć np. pierwszy akapit w danym rozdziale i np. usunąć z niego wcięcie akapitowe.
- Jakie masz dzieci? – Z kolei to pytanie pozwala uzyskać informację o tym, jakie inne elementy są zaszyte wewnątrz elementu, do którego kierujemy pytanie. W powyższym przykładzie odpytanie tagu <data> pozwoli nam stwierdzić, że w środku znajduje się <lang> oraz <src>, ich kolejność oraz liczbę wystąpień.
Niestety możliwości większości programów przetwarzających tekst kończą się na pytaniu o nazwę tagu, w którym znajduje się dana treść, ewentualnie jednego lub dwóch z powyższej listy, która i tak pokazuje tylko typowe rzeczy, które operator musi mieć pod ręką, żeby móc całkowicie automatycznie przełamać daną treść.
Na czym tak naprawdę polega różnica?
Kluczowa różnica z punktu widzenia wydawcy (bo przecież ta perspektywa jest najważniejsza) jest taka, że nie musi się zanadto przykładać do eksportu i ponosić kosztów związanych z wyeksportowaniem materiałów w jakiś określony sposób. Im większe możliwości oprogramowania DTP, którym dysponuje studio, tym mniej obowiązków ciąży na wydawcy i tym większą wydawca ma pewność, że materiał, który do niego wróci ma tę samą formę i treść, którą przekazał do studia.
Możliwość budowania dodatkowych struktur i tworzenia zaawansowanych siatek warunków pozwala uniknąć błędów, bezlitośnie ujednolica ostylowanie (co czasem pozwala znaleźć błędy w samej bazie danych) i oszczędza czas zarówno wydawcy jak i operatorowi, który pracuje nad publikacją.
Ze względu na te wszystkie czynniki zawsze staramy się pracować w jak najwyższym standardzie i namawiać wydawców do przyjrzenia się językowi XML i podobnym rozwiązaniom, które, choć na pierwszy rzut oka mogą się wydawać trudne do przełknięcia, na długą metę dają ogromne możliwości i oszczędności.