Systemy CMS (DMS) w XML

Pojęcie i koncepcja

Wzrost popularności standardu XML i systemów zarządzania treścią (CMS – Content Management System – albo w tym przypadku konkretnie DMS – Document Management System) spowodowało, że na rynku pojawia się coraz więcej rozwiązań oferujących obsługę treści w standardzie XML. W niniejszym artykule postaramy się opisać i pokazać od podstaw rolę XML w takim systemie, jakie daje możliwości i, przede wszystkim, jakie są jego ograniczenia. W założeniu system (CMS) DMS powinien obsługiwać całość procesu gromadzenia i przetwarzania dokumentów – od pomysłu aż po dowolną formę publikacji.

Środowisko CMS rozwija się bardzo dynamicznie i staje się coraz bardziej skomplikowane. Na pewno artykuł ten nie udzieli odpowiedzi na wszystkie pytania i nie poruszy wszystkich zagadnień. To, co dziś jest ograniczeniem, jutro może się okazać nową funkcjonalnością. Celem tego artykułu jest wyjaśnienie pojęć i przybliżenie koncepcji systemów CMS (DMS) opartych na XML w aspekcie biznesowym, czyli o czym warto pamiętać przy wyborze rozwiązania i według jakich kryteriów prowadzić poszukiwania.

Wykorzystanie XML w systemach CMS (DMS)

Jest kilka kluczowych funkcji, które w tych systemach pełni język XML:

• Tworzenie treści
• Komunikacja
• Wymiana treści
• Przechowywanie
• Publikowanie

Wszystkie wymienione funkcje zostaną wyjaśnione w dalszej części artykułu zaczynając od kwestii podstawowych, a kończąc na omówieniu zaawansowanych elementów oraz problemów, na które należy zwrócić uwagę.

Komunikacja

Fakt, że dwa systemy są zapisane w standardzie XML, wcale nie oznacza, że będą mogły swobodnie wymieniać informacje między sobą. Każdy z nich może być oparty na innym „dialekcie”, a dokumenty mogą mieć zupełnie odmienną strukturę metadanych. W takich sytuacjach z reguły tworzy się systemy pośrednie, których jedynym zadaniem jest sprowadzanie danych z różnych systemów do wspólnego mianownika i zapisanie ich w formie, która zostanie zrozumiana przez adresata.

Problemem takich rozwiązań jest to, że są uszyte „na miarę”. Każdy kolejny system może być oparty o nowy dialekt, przez co jego wdrożenie wymaga dostosowania również systemów pośrednich („tłumaczy”), by mógł wymieniać dane z pozostałymi systemami. Dlatego właśnie powstały uniwersalne standardy, według których systemy oparte o XML wymieniają informację bez konieczności konwertowania i dostosowywania zapisu. Jako przykłady można podać choćby RSS czy NewsML, oba oparte o XML. Producenci oprogramowania XML-CMS coraz częściej oferują możliwość natywnej komunikacji w tych standardach.

W procesie wyboru rozwiązania należy zwrócić uwagę, które standardy obsługuje i porównać, czy pozostałe wdrożone systemy będą, bez ingerencji „tłumaczy”, porozumiewać się z nowym. Zachowanie płynnej, bezstratnej komunikacji jest trudne do przecenienia.

Publikowanie

Wykorzystanie XML, a zwłaszcza w powiązaniu z XSL (XML Stylesheet Language) staje się coraz bardziej popularne. XSL, na przykład XSLT lub XPATH pozwalają automatycznie przetwarzać dokumenty XML do celów prezentacji albo do konkretnego formatu. Dzięki temu możliwe jest znaczne zautomatyzowanie procesu publikacji, zwłaszcza publikacji pochodzących „z jednego źródła”. O publikacjach pochodzących z jednorodnego źródła mówimy wtedy, kiedy warstwa merytoryczna treści jest całkowicie oddzielona od typograficznej. Korzystając z takiego źródła możliwe jest symultaniczne generowanie publikacji do odczytu w różnych mediach (druk, formaty elektroniczne, strony internetowe etc.). Faktem jest, że istnieją inne, równoważne technologie, które mają podobne (a w niektórych aspektach nawet większe) możliwości, na przykład w warstwie bazy danych. Warto jednak pamiętać, że ujednolicenie bazy technologicznej pozwala znacznie zmniejszyć bolesność wdrożeń kolejnych systemów i ograniczyć liczbę zatrudnianych specjalistów-administratorów. Optymalizacja procesu publikacji wymaga tworzenia treści w sposób jednorodnie ustrukturyzowany.

Tworzenie (strukturyzacja) treści

Cała potęga XML kryje się w odpowiednim ustrukturyzowaniu powstających treści. Oznacza to konieczność porzucenia wszystkich metod tworzenia treści w sposób bezpośrednio związany z jej wizualizacją i przeniesienie całego procesu do środowiska, w którym treść powstaje w sposób kontrolowany. Jest to proces bardzo skomplikowany, ale trzeba pamiętać, że:

• Wydawnictwa muszą odejść od standardowych procesorów treści jak Microsoft Word, ponieważ nie istnieje żadna metoda automatycznej konwersji niestrukturyzowanej treści do postaci XML.
• Istnieje szereg ulepszeń, które mogą usprawnić pracę autorów w środowisku strukturyzowanym.
• Środowisko XML nie musi dotyczyć pracy większości przeciętnych użytkowników. Fakt, że powstające treści są strukturyzowane do postaci XML może (i powinien) być całkowicie niewidzialny, przebiegać w tle.
• Niektóre systemy szczycą się kompatybilnością z XML poprzez wykorzystanie xHTML. Niestety wykorzystanie xHTML nie jest w żaden sposób lepsze czy bardziej wydajne od wykorzystania zwykłego języka HTML, z którym pracował nawet Microsoft Word 97.
• Wykorzystanie jakiejkolwiek formy HTML jest wysoce niepożądane, bo ogranicza niemal do zera dodatkowe możliwości oferowane wydawcy przez XML.
• HTML to strukturyzowanie dokumentu jedynie w warstwie typograficznej, a podstawowym założeniem budowania bazy treści jest oderwanie merytoryki od typografii. HTML nie zawiera w sobie żadnych informacji merytorycznych.

W chwili obecnej wydawca ma do wyboru szereg systemów dedykowanych do pracy w języku XML. Jednak z powodu działania wielu niezależnych czynników, takich jak np. różnice w procesach produkcyjnych w różnych krajach, gwałtowne zmiany technologiczne zachodzące na rynku wydawniczym, rozwiązania te często nie spełniają oczekiwanych założeń. Nierzadko przeprowadzenie zmian w procesie produkcji niezbędnych, by wdrożyć dane rozwiązanie, przekracza możliwości wydawcy albo jest po prostu zbyt uciążliwe. Wtedy warto zastanowić się nad rozwiązaniem „szytym na miarę” z zachowaniem najlepszych, rynkowych standardów. Program „z pudełka” niemal na pewno będzie rozwiązaniem tańszym, jednak myśląc perspektywicznie oprogramowanie dedykowane prawdopodobnie okaże się bardziej efektywne i lepiej dostosowane do wewnętrznych procesów produkcyjnych w wydawnictwie.

W procesie dokonywania wyboru i oceny warto skupić się na konkretnym przełożeniu wdrożenia danego rozwiązania na cele biznesowe. Do kluczowych aspektów można z całą pewnością zaliczyć prostotę wykorzystania preferowanego rozwiązania dla twórców treści czyli autorów, którzy są kluczowym i bardzo trudnym do opanowania ogniwem w procesie pracy w środowisku strukturyzowanym. Bardzo ważna jest też kompatybilność z innymi, już wdrożonymi rozwiązaniami, np. bazami ilustracji czy systemami obiegu dokumentów, warunki licencyjne, czy zabezpieczenia dostępu (zwłaszcza w warstwie treści).

Przechowywanie

Większość procesów zachodzących wewnątrz oprogramowania CMS (DMS) jest niedostrzegalna dla użytkowników. Oznacza to, że programiści mają dużą swobodę w projektowaniu swoich rozwiązań, co może powodować problemy w komunikacji z innymi systemami. Ze względu na fakt, że nie wszystkie rozwiązania korzystają z uznanych standardów, nie zawsze dwa programy, w teorii oparte o język XML, będą w stanie swobodnie wymieniać dane. Powodów takiego stanu rzeczy jest wiele – nie wszyscy producenci oprogramowania chcą dopasować swoje systemy do uznanych standardów i nie wszyscy potencjalni odbiorcy mieszczą się w ich ograniczeniach. Czasami, aby spełnić wymogi konkretnego odbiorcy, trzeba wyjść poza standard albo wręcz stworzyć własny od podstaw.

W warstwie biznesowej przekłada się to na zerowe znaczenie procesów zachodzących w środku CMS (DMS). W praktyce nie jest istotne, czy baza danych będzie oparta o XML czy SQL. Kluczowe jest to, w jakim języku CMS porozumiewa się z systemami zewnętrznymi. Dlatego przy wyborze należy pamiętać o API, które będzie drogą tej wymiany. Profesjonalne oprogramowanie powinno zawierać bardzo rozbudowane API z pełną specyfikacją, by w przyszłości móc dopasować do siebie kolejne elementy informatycznej układanki do obsługi procesów wydawniczych.

Wymiana treści

System CMS (DMS) powinien być tylko jednym z elementów systemu obsługującego procesy w wydawnictwie. Wraz z wdrażaniem kolejnych programów wyspecjalizowanych w obsłudze poszczególnych elementów procesu wydawniczego (np. edytorów XML, systemów obsługi baz ilustracji itp.) coraz ważniejsza staje się kwestia wymiany treści między tymi elementami. W praktyce system CMS jest najczęściej połączony z:

• Bazami ilustracji
• Edytorami
• Systemami archiwizacji
• Sklepami internetowymi (np. pay per view)
• Systemami wewnętrznego obiegu dokumentów
• Systemami księgowymi

Najbardziej rozbudowane są oczywiście systemy związane z internetem. Znaczące kroki poczyniły tu zwłaszcza takie firmy, jak Sun i Microsoft ze swoimi platformami J2EE i .NET. Są to rozwiązania dynamicznie rozwijane i stale dostosowywane do nowych potrzeb rynku czy rozwiązań technologicznych, dzięki czemu wdrażanie nowych formatów czy systemów jest stosunkowo tanie i bezbolesne.

Znacznie gorzej układa się współpraca z innymi elementami procesu wydawniczego, zwłaszcza systemami księgowymi, gdzie wykorzystywane oprogramowanie zależy od wielu czynników, a kompatybilność z jakimikolwiek zewnętrznymi systemami pełni bodaj najmniejszą rolę.

Dlatego przy wyborze gotowego lub projektowaniu własnego oprogramowania CMS (DMS) należy pamiętać o tym, że nie musi ono robić wszystkiego i obsługiwać wszystkich elementów procesu wydawniczego. Z biznesowego punktu widzenia nie ma żadnej różnicy między jednym „kombajnem” obsługującym proces od pomysłu do gotowej publikacji, a zestawem niezależnie rozwijanych programów połączonych wewnętrznym protokołem API, z którym wszystkie te systemy są zgodne. Dlatego tak ważna jest funkcjonalność API oraz obszerna dokumentacja – żaden system nie uzyska informacji, których inny system po prostu nie chce udostępnić, bo API tego nie umożliwia.

W przypadku systemów dedykowanych możliwe jest stworzenie siatki docelowych rozwiązań, zaprojektowanie centralnego elementu systemu w oparciu o przewidywane zapotrzebowania oraz planowane stopniowe dołączanie kolejnych, niezależnych programów do obsługi poszczególnych elementów procesu wydawniczego. Wraz ze stopniowo wdrażanymi elementami można dopasować systemy wymiany danych między nimi, chociaż trzeba pamiętać, że z każdym kolejnym dodawanym elementem układanki staje się to coraz bardziej skomplikowane, ponieważ zmiany trzeba wprowadzić w każdym już wdrożonym oprogramowaniu.

Podsumowanie

Celem tego artykułu jest określenie podstawowych zagadnień, na które należy zwrócić uwagę w toku zastanawiania się nad wdrożeniem standardu XML w procesach wewnętrznych wydawnictwa. Szczegółowe opracowania powinni stworzyć architekci systemu w ramach analizy wstępnej (przy oprogramowaniu dedykowanym) lub dział informatyczny w procesie wyboru rozwiązań „z pudełka”. W generalnym ujęciu, w szale automatyzacji i digitalizacji, nie należy tracić z oczu celu biznesowego, którym jest maksymalizacja wartości treści przy jednoczesnym ograniczeniu kosztów publikacji i optymalizacji procesu produkcyjnego. Poprawnie wdrożone rozwiązanie XML, zwłaszcza takie, które zostanie zaprojektowane specjalnie na potrzeby danego wydawcy, z całą pewnością jest w stanie te cele biznesowe osiągnąć.