Masarykova univerzita Fakulta informatiky
Bakalářská práce
Tvorba webových stránek s ohledem na nevidomé uživatele
Roman Kabelka
2007
Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje a prameny, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.
Shrnutí Odlišnosti způsobu práce nevidomého uživatele s osobním počítačem se odrážejí i na přístupu k informacím skrze Internet. Z důvodu textové linearizace bychom měli brát na tyto uživatele ohled, protože převod do prostého textu je v současné době nejpoužitelnějším způsobem zpřístupňování webových stránek. Jak vyplývá z prioritních pravidel pro přístupnost, jež jsme si uvedli, nejedná se o zásadní ústupky pro běžné návštěvníky, naopak přinášejí výhody i pro strojové zpracování vyhledávacími roboty. V dnešní době renomovaní webdesigneři tyto směrnice dodržují, neboť prezentace, která prošla auditem přístupnosti, je dobrou vizitkou pro tvůrce. Zatímco koncepce webových stránek orientovaná na vzhledovou příjemnost a požadavky nevidomých se nějak vážně nekryjí, v procesu tvorby samotných prezentací je třeba zavést specifičtější hranice určující cílovou skupinu uživatelů. WYSIWYM pojetí editace, blízké transformaci screenreaderů, je vzhledově smýšlejícím uživatelům poněkud nevlastní, a tak zanedbávané. Míra těchto prostředků automaticky zasahujících do chápání webových stránek nevidomými uživateli je hlavním důvodem, proč v paletě dostupných editorů neexistuje takový, který by uspokojil všechny nároky obou skupin. Nicméně zde prezentovaný HTX Designer díky své nízkoúrovňovosti může najít své příznivce i mezi zkušenými uživateli, kteří dosud pracovali se strukturními editory.
Klíčová slova Webová prezentace, editor webových stránek, přístupnost, nevidomý uživatel, screenreader, textová linearizace, WYSIWYM editor
2
Obsah Shrnutí
1
1.
ÚVOD
5
2.
WEBOVÁ PREZENTACE
5
2.1.
Vymezení Pojmů
5
2.2. Kategorizace Prezentací 2.2.1. Účel 2.2.2. Struktura 2.2.3. Přístupnost pro znevýhodněné uživatele 2.2.4. Další kategorie
6 6 6 6 7
2.3. Editory webových stránek 2.3.1. Strukturní editory 2.3.2. WYSIWYG editory 2.3.3. WYSIWYM Editory
7 7 7 8
3.
8
NEVIDOMÝ UŽIVATEL A PROHLÍŽENÍ WEBOVÝCH STRÁNEK
3.1.
Princip práce a omezení
8
3.2.
Režimy čtení
8
3.3. Přístupnost 3.3.1. Přístupnost netextových informací a doplňkových technologií 3.3.2. Orientace ve stránce a dosažitelnost informací 3.3.3. Validní kód
4.
10 10 11 11
NEVIDOMÝ UŽIVATEL A TVORBA WEBOVÝCH STRÁNEK
12
4.1.
Dosavadní situace
12
4.2.
Předpoklady přístupného editoru
12
5.
HTX DESIGNER – APLIKACE
13
5.1. Základní charakteristiky 5.1.1. Systémové požadavky 5.1.2. Bezpečnost 5.1.3. Možnosti editace značkovacích jazyků
13 13 14 14
5.2. Součásti 5.2.1. Editor schémat 5.2.2. Správce projektů 5.2.3. Editor dokumentů
14 14 16 16
3
5.3.
Elementy
17
5.4.
Generování prezentací
18
6.
HTX DESIGNER – IMPLEMENTACE
19
6.1.
Třídy
19
6.2.
Moduly
19
6.3.
Uchovávání XML dokumentů v relační databázi
19
7.
ZÁVĚR – BUDOUCÍ VÝVOJ
20
8.
POUŽITÉ ZDROJE
21
9.
PŘÍLOHA – DATOVÉ STRUKTURY
21
9.1.
Schémata
21
9.2.
Projekty
23
9.3.
Dokumenty
24
4
1. Úvod Neexistuje skupina zdravotně postižených, kterou by překotný vývoj informačních technologií posledních dvaceti let nezasáhl více než zrakově postižené. Nejprve to byl mikropočítač Eureka A4 znamenající v oblasti efektního využití pracovního, ale i volného času hotovou revoluci. Další nové obzory se otevřely díky digitalizaci textů OCR softwarem, jenž oproti minulosti, kdy texty musely být ručně přepisovány do braillova písma, zpřístupňoval poměrně jednoduchým způsobem informace v tištěné formě. Nepochybně jedním z nejzásadnějších z tohoto výčtu je Internet, protože komunikační schopnosti a informační obsáhlost světové sítě dovedly proces začlenění zrakově postižených do běžné společnosti téměř k dokonalosti. Nejvážnější bariéry se přesunuly z technické do sociální oblasti, kde závisí především na osvětě a pochopení problematiky integrace. Ta spočívá především na přiměřené míře podpory v životě bez snižování dojmu nezávislosti zrakově postiženého a na individuálním přístupu k schopnostem pracovního uplatnění, jenž je přetrvávající komplikací a velkou bariérou. Je zejména opomíjena úloha Internetu jako nástroje prodeje vlastních schopností a dovedností člověka, který by touto cestou mohl být snáze zapojen do pracovního procesu. Jedním z důvodů je absence uživatelsky příznivé aplikace pro prezentování na WWW splňující požadavky jak na vlastní tvorbu, tak na výsledný produkt. Právě těmto požadavkům se budeme blíže věnovat v této práci. Na začátek vysvětlíme pojem „webová prezentace“ a z obecné roviny se zaměříme na aspekty kategorizace prezentací a na nástroje pro jejich tvorbu. Poté zúžíme svou pozornost na vztah zrakově postiženého uživatele a webových technologií, při čemž nás bude zajímat nejen získávání informací skrze službu WWW, ale i situace v oblasti tvorby hypertextových dokumentů samotnými uživateli. Z těchto podkladů vyjdeme a nastíníme možnost řešení zanedbávaného problému, jak umožnit zrakově postiženému uživateli tvořit vlastní webové stránky. Následně tyto poznatky využijeme při konkrétní implementaci v podobě online aplikace „HTX Designer“. Na závěr po rozboru jednotlivých součástí aplikace naznačíme další možný vývoj aplikace a její nasazení jako globální služby.
2. Webová Prezentace 2.1. Vymezení Pojmů Webovou prezentací rozumíme sadu navzájem provázaných hypertextových stránek se společným jmenovatelem, kterým je prezentovaný objekt – firma, osoba, hobby… Takovou prezentaci nazýváme někdy website či prostě web a bývá charakterizována doménovým jménem v URL adrese k jednotlivým dokumentům. Hypertextový dokument (webovou stránku) budeme v dalším kontextu chápat jako dokument ve značkovacím jazyce HTML či XHTML, k němuž přistupujeme na server přes protokol http. Budeme-li mluvit o prohlížení webových stránek nevidomým uživatelem a neuvedeme-li jinak, budeme mít na mysli světově nejrozšířenější softwarovou konfiguraci – operační systém
5
Microsoft Windows, internetový prohlížeč Microsoft Internet Explorer a odečítač obrazovky Jaws For Windows.
2.2. Kategorizace Prezentací Abychom mohli v našich aplikacích řešit komplexní správu celé webové prezentace, je potřeba přizpůsobit jejich možnosti typům informací a různým pohledům, s kterými se můžeme setkat. Toto rozdělení může být užitečné i pro snížení abstraktní povahy výuky nevidomého uživatele při práci s webovým prohlížečem.
2.2.1.
Účel
Toto hledisko je pro návrh webové prezentace nejzajímavější, protože umožňuje celý proces tvorby výrazně zrychlit a nabízí elegantní řešení i pro méně zkušeného uživatele v této oblasti. Bohužel vše postihující popis účelů, ke kterým mohou prezentace sloužit neexistuje, a tak často implementujeme šablonovací systém splňující předpoklad, že stránky sloužící k účelu prezentace nějakého objektu budou obsahovat informace pro ten daný objekt charakteristické – např. u obchodu s elektronikou očekáváme adresu prodejny, telefon a otevírací dobu.
2.2.2.
Struktura
Struktura ***uspořádání stránek do komplexní prezentace a navigace mezi nimi patří úkoly, na které by jsme měli klást obzvláštní důraz při návrhu. Tato struktura se často odvíjí od účelu, nicméně není to podmínkou a i např. prezentace typu vizitka nemusí být pouze jedinou stránkou. Struktura sady webových stránek je orientovaný graf, ve kterém jsou uzly jednotlivé stránky a hrany odkazy vedoucí z jedné stránky na druhou. Mezi nejběžnější patří strom, sekvence, samostatná stránka, rozcestník… Univerzální v tomto ohledu je strom, protože lze skrze něj vyjádřit většinu obvyklých vztahů.
2.2.3.
Přístupnost pro znevýhodněné uživatele
Eticky, ale i marketingově (jde-li o stránky obchodní povahy) je vhodné, aby prezentace byla přístupná technicky či zdravotně znevýhodněným uživatelům. V zásadě rozlišujeme tři druhy přístupnosti – nepřístupné, z části přístupné a přístupné. Z praktického hlediska u částečně přístupných prezentací jde o stejnou situaci jako u nepřístupných, neboť nelze zaručit, jakou informaci uživatel bude při návštěvě stránek požadovat. Rozdíl hraje pouze to, zda nepřístupná informace souvisí s tématem prezentace – např. dekorativní grafika stránek není podstatná téměř v žádném kontextu. Technické bariéry vznikají uživateli, nachází-li se v nestandardním prostředí nebo používá-li zařízení s omezenými schopnostmi periferií – např. světelnost displeje kapesního počítače.
6
Bariérami, které jsou kladeny v důsledku zdravotního postižení, se budeme zabývat podrobněji dále. Tyto bariéry vznikají z důvodu, že zdravotně postižený člověk některé standardní periferie nemůže vůbec či velmi těžce ovládat (např. myš) a často používá periférie specifické pro jeho druh postižení – hlasový výstup, braillský řádek.
2.2.4.
Další kategorie
Prezentace můžeme dále členit podle dalších kritérií: Rozsah – počet stránek, míra sdělených informací. Použité technologie – Zajímá nás technologie, kterou byla prezentace vytvořena (HTML, Docbook, Macromedia Flash…). Forma prezentace – V elektronických prezentacích nejsme omezeni jen na psaný text a využití multimédií pro názorné sdělení některých detailů se přímo nabízí (animace, zvuk, video…).
2.3. Editory webových stránek Přestože HTML patří mezi značkovací jazyky, jejichž kód je možno číst a psát v obyčejném textovém editoru, existuje celá paleta aplikací kladoucích si za úkol uživateli psaní usnadnit.
2.3.1.
Strukturní editory
Mezi webdesignery jsou nejrozšířenější strukturní editory dávající plnou kontrolu nad editovaným kódem, avšak disponují nad rámec univerzálního textového editoru nástroji pro zlepšení orientace v kódu a pro zjednodušení vkládání obvyklých struktur, typických pro HTML, pomocí nejrůznějších šablon, klávesových zkratek či průvodců. Jejich součásti také často zahrnují kontrolu validity kódu a existence odkazů, čištění kódu od nadbytečných konstrukcí, komunikaci se serverem pro přímé uveřejňování stránek… Rovněž většinou podporují přidružené technologie jako kaskádové styly nebo javascript pro dynamické HTML.
2.3.2.
WYSIWYG editory
WYSIWYG editory (what you see is what you get) naproti tomu nabízejí pro uživatele velmi intuitivní prostředí, které nevyžaduje jakoukoli znalost HTML, vše je editováno a zobrazováno tak, jak je uživatel zvyklý z internetového prohlížeče. Preferovanému nasazení tohoto způsobu tvorby stránek však brání několik aspektů, které mají základ v nedokonalosti generování kódu a v neznalostech uživatele (nejčastěji typografické zvyklosti), což často ústí ve stránky, jež nemohou být označeny jako platné podle obvyklých standardů.
7
2.3.3.
WYSIWYM Editory
Blízko pojetí WYSIWYG editorů jsou tzv. WYSIWYM editory (What You See Is What You Mean), u nichž opět dochází k odstínění zdrojového kódu od uživatele, ale je kladen důraz více na sémantiku stránky než grafickou formu. Toto logické zvýrazňování kontextu namísto grafického nejvíce rozvinul dokumentový procesor LYX. Přestože jde o nejméně obvyklý způsob tvorby stránek, vzhledem k zrakově postiženým uživatelům jde o vhodný náhled na obsah editované stránky.
3. Nevidomý uživatel a prohlížení webových stránek 3.1. Princip práce a omezení Pro další výklad je nutno zdůraznit, že prakticky nevidomý uživatel pracuje pouze s textovými daty, které jsou mu zobrazovány na braillském řádku nebo jsou vyslovovány syntetizérem řeči. Protože jak braillský řádek omezený běžně velikostí čtyřiceti znaků, tak hlasový výstup vyslovující jen informaci o aktivním prvku na obrazovce či o textu pod kurzorem, neurčí-li uživatel jinak, nejsou schopny rozumně postihnout rozmístění objektů na obrazovce v rámci globálního pohledu, je nutné grafické rozhraní, mezi něž patří i webová stránka, převést na přijatelnou formu pro tyto výstupy. Odečítač obrazovky (dále jako screenreader), má za úkol sledovat dění na obrazovce počítače a podávat uživateli výše zmíněnými způsoby informace o změnách.
3.2. Režimy čtení Screenreader pracuje v internetovém prohlížeči ve dvou hlavních režimech, mezi nimiž lze plynule přecházet. První, nevirtuální režim, pracuje se stránkou jako s jakýmkoli dialogovým oknem. Při pohybu po prvcích dialogu jsou procházeny odkazy a formulářové prvky – je čten jejich typ a obsah. Ostatní obsah stránky není čten, je jedině možné nechat si plynule přečíst viditelnou část na obrazovce. Tento režim se také někdy nazývá jako vkládací, protože v něm můžeme vpisovat text do editačních polí a manipulovat s dalšími formulářovými prvky. V druhém, virtuálním režimu, je pro screenreader v prostředí 32-bitových Windows pomocí vrstvy MSAA zachycen obsah stránky jako DOM model. Tato stromová struktura je následně převedena dle uživatelských předvoleb a daných postupů na lineární tok textu, v němž jsou vyznačeny nejvýznamnější kontexty. Přechody mezi kontexty jsou při plynulém čtení i při procházení stránkou po řádcích či jiných úsecích oznamovány. Akce prováděné v tomto režimu jako např. aktivace odkazu, jsou posílány do nevirtuální vrstvy, kde je objektu dán fokus a je aktivována jeho akce – u odkazu onClick. Rovněž je-li zjištěna změna původního dokumentu, je znovu proveden převod a obsah virtuálního prohlížeče aktualizován.
8
Pokud screenreader je schopen ve stránce detekovat kontexty tabulek, nadpisů, seznamů atd…, nabízí horké klávesy pro přesun vpřed či vzad na nejbližší daný kontext, což umožňuje zlepšit orientaci z výše uvedených důvodů v rozsáhlých stránkách. Příklad 3.2.: Ukázka části stránky převedené screenreaderem Fakulta informatiky MU Odkaz: Grafika: Logo FI MUNI ALT+1 Fakulta informatiky Masarykovy univerzity Odkaz do této stránky: Hledání | Odkaz: English version » Fakulta informatiky Nadpis úrovně 2: Aktuality Seznam 2 položek Odrážka: Odkaz: Státnicové otázky pro Bc a Mgr studium Odrážka: Odkaz: Studijní program Koordinátor v oblasti ICT Konec seznamu Odkaz: Starší aktuality Nadpis úrovně 2: Fakulta Seznam 8 položek Odrážka: Odkaz: O fakultě Odkaz: ofakulte.xhtml Odrážka: Odkaz: Dlouhodobý záměr FI (pdf) Odrážka: Odkaz: Úřední deska Odkaz: (autentizovaný přístup) Odrážka: Odkaz: Dokumenty a právní normy Odrážka: Odkaz: Orgány fakulty, Odkaz: organizační struktura, Odkaz: seznamy (stránky MU) Odrážka: Odkaz: Výběrová řízení (stránky MU) Odrážka: Odkaz: Ceny získané pracovníky a studenty FI MU Odrážka: Odkaz: Hodnocení podmínek Odkaz: studenty a Odkaz: zaměstnanci Konec seznamu ...
9
3.3. Přístupnost Přístupnost je obecně termín užívaný k vyjádření míry použitelnosti systému co nejvíce lidmi. Silně souvisí s univerzálním návrhem produktů (v našem případě webových stránek) tak, aby byly použitelné pro uživatele bez rozdílu, jestli jsou či nejsou nějak omezeni. Konsorcium W3C ve své směrnici WCAG formulovalo přístupnost do čtyř bodů: 1. Obsah musí být postřehnutelný (viditelný, pochopitelný). 2. Prvky rozhraní musí být ovladatelné. 3. Obsah a ovládací prvky stránky musí být srozumitelné. 4. Obsah by měl být natolik robustní, aby s ním bylo možno pracovat prostřednictvím současných či budoucích uživatelských prostředků (včetně asistivních technologií). Konkrétně pak potřebami a bariérami zrakově postižených uživatelů se v České republice zabývá projekt Blind friendly web při Sjednocené organizaci nevidomých a slabozrakých. Metodický návod, který je výsledkem činnosti tohoto projektu, obsahuje soubor pravidel pro zpřístupnění obsahu stránek zrakově postiženým. Pravidla jsou rozčleněna do tří úrovní, při čemž my se zmíníme o pravidlech s nejvyšší prioritou na první úrovni. Rovněž vynecháme opatření týkající se slabozrakých uživatelů, poněvadž jejich požadavky na vizuální parametry obsahu stránky nijak neovlivňují naše další směřování v této práci.
3.3.1.
Přístupnost netextových informací a doplňkových technologií
Jak jsme již zmínili, jelikož nevidomý uživatel výhradně pracuje s textovými informacemi, je třeba jakoukoli jinou, zvláště vizuální formu sdělení, převést na textovou alternativu. V současné době žádný ze screenreaderů nedisponuje automatizovaným převodem netextových informací, proto tyto alternativy musíme do stránky implicitně zahrnout, jde-li obzvlášť o aktivní prvky stránky - např. grafická tlačítka. Rovněž u tabulek, které nesou meta informace v grafickém znázornění, je třeba zajistit, aby linearizovaná tabulka po řádcích byla pochopitelná. Není-li možné tento požadavek splnit, musíme ji doplnit o alternativní popis. Vzhledem k poměrné náročnosti převodu webové stránky na formu použitelnou pro nevidomého uživatele jsou vynechávány všechny doplňkové technologie stránek, jako jsou Javascript, kaskádové styly, applety atd., což je zapříčiněno i faktem, že odhadnout chování takových doplňků je často nereálné. Pokud tyto technologie vyvoláním nějaké své akce ovlivňují v rozumné míře přímo obsah stránky, není použití na překážku. V ostatních případech by jsme se měli vyvarovat situací, kdy sdělovací hodnota prvku mimo rámec jazyka HTML zůstává skryta.
10
3.3.2.
Orientace ve stránce a dosažitelnost informací
Problém bezbariérového přístupu k linearizovaným tabulkám může být v uspokojivé většině případů řešen vhodným návrhem a rozsahem tabulky. Obecně lze říci, že pokud vlastnosti objektu jsou nasázeny do řádku a nikoli sloupce, bývá taková tabulka pochopitelná, nepřekročíli počet sloupců určitou mez. Z hlediska přístupnosti není též ideální dodnes mezi tvůrci stránek oblíbené využívání tabulky jako pravoúhlé sítě pro rozmístění objektů na stránce. Kromě toho, že nevidomý uživatel nemůže jednoduše pohledem spojit související objekty v síti, může linearizace tabulky důležité informace odsunout v textu na místo, které je při absenci dalších orientačních prvků velice nepohodlně dosažitelné. Informace v tabulkách jsou přebírány screenreaderem tak, jak následují po sobě ve zdrojovém kódu stránky. Podobnou strukturou sloužící k rozvržení stránky jsou rámy, které v zásadě nejsou překážkou, musí mít pouze vhodně zvolené popisky a napevno daný svůj účel, aby bylo snadné předvídat, do kterého rámu se nový odkaz bude otevírat. Nejdůležitější záchytné body ve stránce pro nevidomého uživatele tvoří odkazy, proto jejich text by měl být jednoznačně odlišitelný od ostatních a jeho význam musí být zřejmý i bez vyčítání okolního kontextu. Toto chování je vyvoláno zejména faktem, že pohybem pouze po odkazech a jejich aktivací se nevidomý nejrychleji naviguje na cílovou stránku, kterou dále podrobně pročítá pro dosažení požadované informace. Druhým aspektem je fakt, že všechny screenreadery nemají virtuální režim jako výchozí, a tak přepínání režimů nemusí být tak pohodlné, jak bývá obvyklé. Nevýhodu vyplývající z lineárního uspořádání stránky pro syntézu řeči a braillský řádek lze velmi efektně kompenzovat správným vyznačováním nadpisů a seznamů. Pokud nadpisy jednotlivých sekcí stránky budou korektně vyznačeny namísto zástupných vizuálních stylů, je možno díky funkcím screenreaderu po těchto nadpisech přeskakovat, a tak dosažení požadované informace ve stránce je velmi rychlé. Toto správné sémantické zvýrazňování má na nevidomého uživatele srovnatelný účinek jako příjemný grafický design na běžného uživatele – návštěvník se rád vrací. Poslední orientační nesnází, jež zmíníme, jsou popisky formulářových polí. Screenreader umí uživateli oznámit správný popisek pole, je-li ten s polem svázán. Pokud tak ve zdrojovém kódu stránky učiněno není, pokoušejí se moderní screenreadery získat popisek s nejbližšího okolního textu, což nemusí vždy vést k uspokojivému výsledku.
3.3.3.
Validní kód
Validita kódu podle některé z norem konsorcia W3C zaručuje, že všechny funkce screenreaderu pro zpřístupnění stránky budou pracovat správně a že při zpracování DOM modelu nedojde k chybám v komunikaci mezi jednotlivými aplikačními vrstvami, které mohou vést až k zatuhnutí prohlížeče, a tak způsobit celkovou nedostupnost stránky.
11
4. Nevidomý uživatel a tvorba webových stránek 4.1. Dosavadní situace Hlavní překážkou pro nevidomého v používání sofistikovaných nástrojů pro tvorbu webových prezentací bývá především uživatelské rozhraní, jež je navrženo pro maximální přehlednost pracovního prostředí, což se projevuje soustřeďováním stavových informací do grafické podoby – např. zvýrazňování syntaxe. V grafickém rozhraní s tímto trendem souvisí používání specifických ovládacích prvků, s nimiž si screenreader není schopen poradit v případě, kdy komponenty v prostředí Microsoft Windows nedědí své vlastnosti od těch standardních. U neznámých prvků pak není zaručitelné rozpoznání stavu, získání textového obsahu a fokusu. Také často se může celé okno aplikace z pohledu screenreaderu jevit jako jeden velký obrázek, potom přístupnost takové aplikace je prakticky nulová. Ze strukturních editorů vyhovují nevidomému uživateli pak jen ty, kde je nutná znalost jazyka HTML a kde se pracuje se zdrojovým kódem na nejnižší úrovni. Editor pouze kontroluje syntaxi, případně doplňuje koncové tagy elementů. V oblasti WYSIWYG editorů nejčastěji panuje problém s rozhraním popsaný výše. Některé screenreadery sice umí zpřístupnit Microsoft FrontPage v uspokojivé míře, ale ani toto řešení není dostatečné pro kvalitní výsledky. S HTML editory se setkáváme nejen ve formě samostatných aplikací, ale i v online modulech redakčních systémů. Pro dostupnost platí řečené výše s tím rozdílem, že i ty nejjednodušší WYSIWYG komponenty používající jako editační plochu jinak standardně přístupné plovoucí rámy, jsou prakticky neřešitelným problémem pro nevidomého uživatele.
4.2. Předpoklady přístupného editoru Jak jsme se mohli přesvědčit v předchozí kapitole, neexistuje editor nabízející nevidomému komfort blížící se srovnatelným zkušenostem běžného uživatele. Rovněž jsme také dospěli k závěru, že vzhledem k technikám zpřístupňování webových stránek se pojetí WYSIWYM editoru blíží našim potřebám nejvíce. Nejdůležitějším přínosem takového editoru musí být příznivý dojem vycházející s principu WYSIWYG nástrojů a u potřeb nevidomého uživatele se soustřeďuje do tří předpokladů: 1. Nebude vyžadována přímá znalost HTML - syntaxe a tagy. 2. Zobrazovat všechny informace o dokumentu v prostém textu tak, jak je uživatel zná z virtuálních nadstaveb screenreaderů při pročítání stránky. 3. Zajistit přehlednou práci se stromovou strukturou dokumentu, což můžeme realizovat vhodným popisem elementů ve stránce a zplošťovat tak strom na dané úrovni. Vzhledem k různorodosti obsahu dokumentu nemůžeme provést plnou linearizaci vlastní pro screenreadery, neboť sémantika elementů jinak opomíjených musí být nyní uživatelem kontrolována.
12
Také validita kódu podle platných norem je udržována už během procesu tvorby. Nabízíme uživateli jen bezpečné funkce nevedoucí k porušení integrity dokumentu – např. nedovolit vložit elementy na daném místě nepovolené. Protože takto navržený způsob práce se orientuje zejména na správnou formu dokumentu, je vhodné zajistit i správu přidružených technologií pro oživení obsahu – obrázky, styly a další soubory ke stažení. I když uživatel zdrojový kód nepíše, manipuluje s dokumentem podle nastíněných pravidel na nízké úrovni, což by při editaci rozsáhlejších dokumentů mohlo vést k desorientaci. Tuto nevýhodu však lze kompenzovat zabudováním šablonovacího systému pohlížejícího na dokument jako na formulář se vstupy, které pro dosažení požadovaného výsledku jen vyplníme, nehledě na to, že lze kód šablon jednoduchým způsobem recyklovat pro různá využití. Pokud zkombinujeme šablonovací systém s prostředky pro údržbu celé prezentace, dostaneme komplexní nástroj pro tvorbu prezentací nejen s formálně správným kódem, ale i systém stránek, v nichž se bude tvůrci i návštěvníkovi dobře orientovat.
5. HTX Designer – aplikace Nyní do této chvíle řečené teoretické podklady převedeme do praktické roviny demonstrací online aplikace pro tvorbu webových stránek s ohledem na nevidomé uživatele „HTX Designer“.
5.1. Základní charakteristiky 5.1.1.
Systémové požadavky
Tento software je vyvinut jako online aplikace, což znamená, že je nezávislý na platformě operačního systému a že jej můžeme ovládat prakticky odkudkoli prostřednictvím webového prohlížeče. Požadavky jsou kladeny na webhosting, na kterém HTX Designer budeme chtít provozovat a kde následně budeme pomocí jeho rozhraní generovat výsledné prezentace: FTP přístup pro nahrání aplikace, její instalaci a pro dodatečné změny práv souborů s úkolem zajistit větší bezpečnost. Skriptovací jazyk PHP 5.0 a vyšší, v němž je celá aplikace napsána. Databáze MySQL 4.0 a vyšší, v níž aplikace uchovává veškerá svá data. Kombinace jazyka PHP a databáze MySQL nám zaručí, že své stránky budeme moci tímto nástrojem vytvářet na drtivé většině webhostingů na trhu a to i na těch, jež poskytují své služby zdarma. Dlouhodobé statistiky vypovídající o masovém nasazení PHP u poskytovatelů free hostingů a objektový model implementovaný v PHP 5.0 nám ručí za univerzální použitelnost s přehledným vnitřním uspořádáním.
13
5.1.2.
Bezpečnost
Bezpečnost námi vytvářených dokumentů je zaručena autentizovaným přístupem a uchováváním veškerých dat v databázi. Z implementačního hlediska by ukládání nehotových dokumentů přímo do XML souborů bylo jednodušší, protože by však práva datových souborů musela být nastavena pro globální zápis, nebylo by možné dokumenty ochránit proti nedovoleným modifikacím.
5.1.3.
Možnosti editace značkovacích jazyků
V HTX Designeru nejsme omezeni pouze na jazyk HTML, univerzální koncepce nám dovoluje vytvářet dokumenty prakticky v jakémkoli značkovacím jazyce založeném na XML. Na druhou stranu tato vlastnost od uživatele očekává, že má povědomí o minimálním základu filozofie XML – dokument tvořený z elementů zanořujících se do sebe, každý element má své atributy. HTX Designer tedy není určen úplným začátečníkům s webem, nýbrž těm, zvláště nevidomým uživatelů, kteří již s tvorbou stránek mají zkušenosti, nicméně kvůli pro ně neuspokojivé situaci okolo HTML editorů jde o činnost časově náročnou s nepřesnými výsledky v důsledku ručního psaní kódu.
5.2. Součásti 5.2.1.
Editor schémat
Abychom mohli vytvářet dokumenty dle standardů a stanovit formální definici značkovacího jazyka daného dokumentu, je třeba implementovat systém pro správu a editaci schémat. Pod pojmem schéma rozumíme soubor charakteristik elementů a jejich atributů včetně specifikace pravidel pro jejich vzájemné zanořování tak, jak je chápe např. schémový jazyk Relax NG. Vlastnosti tohoto jazyka jsou v HTX Designeru rozšířeny o uživatelsky přívětivější alternativní názvy elementů a atributů za účelem snížit nutnost znalosti tagů, jenž nemusí být vždy zřejmé, a o určení popisných atributů reprezentujících stručně obsah elementu. Příkladem využití popisných atributů mohou být elementy obrázku a odkazu. Obrázek nejlépe identifikuje jeho alternativní popisek, zatímco u odkazu jeho vlastní obsah. Základní organizační jednotkou schémata je skupina sdružující elementy či atributy a další podskupiny do tématických celků pro pozdější využití. Navíc kromě typu určujeme povinnost výskytu každého prvku a uspořádání, tedy vztah, v jakém se obsah skupiny nalézá. Rozlišujeme tři uspořádání: Sekvence – Prvky v dokumentu musí následovat po sobě v analogickém pořadí jako ve skupině – např. jedině pořadí hlavička, tělo, zápatí má smysl. Množina – Prvky skupiny mohou být uspořádány v dokumentu v libovolném pořadí. Mix – Totéž co množina, navíc však rozšířená o možnost prokládání prostým textem.
14
Uvedená uspořádání mají význam jen pro skupiny elementů, u atributových je pro naše potřeby jediným smysluplným uspořádáním množina. Atribut neboli vlastnost elementu je prvek napevno svázaný s nějakou atributovou skupinou. Jeho základní chování je určeno typem, typovými omezeními a předdefinovanou hodnotou, což dovoluje zajistit pro uživatele efektní zadávání jejich hodnot v podobě příslušných vstupů – např. editační pole pro text, zaškrtávací pole pro logickou hodnotu. Elementy jsou vlastní stavební kameny dokumentu, jejich možnosti jsou kromě výše uvedených vlastností specifikovány přidruženými atributovými a elementovými skupinami, jež určují výčet atributů a typ povoleného obsahu elementu. Tento systém oddělení charakteristik od elementů umožňuje jednoduše dosáhnout opětné využitelnosti a zlepšení orientace v rozsáhlejších schématech. Posledním krokem k validitě dokumentu dle předepsaného schémata je identifikace namespace pro XML a úvodní hlavičky pro SGML, popř. procesní instrukce, které jsou zahrnuty v základních vlastnostech.
Příklad 5.2.1.: Ukázka organizace schémata Element: Tag: html Popis: dokument Elementová skupina: Atributová skupina: Element: Tag: head Popis: hlavička Elementová skupina: Atributová skupina: Element: Tag: body Popis: tělo Elementová skupina: Atributová skupina: Skupina Skupina Skupina Skupina Skupina Skupina
html.content html.attr
head.content head.attr
block.content body.attr
element.ref: ([id]) html.content: (head,body) html.attr: (element.ref|xmlns) head.content: ([meta]|[style]|title) head.attr (element.ref) body.attr: (element.ref|[onload])
15
5.2.2.
Správce projektů
HTX Designer pro organizaci stránek v prezentaci a správu dalších přidružených objektů přispívajících ke zkvalitnění výsledku nabízí sadu níže popsaných modulů. Strukturu prezentace HTX Designer uspořádává do stromu, jenž dovoluje implementovat i ostatní struktury stránek. Každá stránka kromě vlastního dokumentu zahrnuje i sadu vestavěných a libovolně definovatelných vlastností, což s výhodou umožňuje zavést v této stromové organizaci dědičnou konfiguraci. Daná stránka dědí vlastnosti rodičovské stránky, nejsou-li předefinovány, a může být doplněna o vlastnosti nové. Tímto způsobem lze zavést jednoznačné vazby mezi souvisejícími stránkami a vytvořit pro každou z nich charakteristický kontext. Kompenzací vůči nízké úrovni editace dokumentu je šablonovací systém dovolující vkládat opakující se bloky stránek a ušetřit si tak práci. Recyklací kódu však možnosti šablon nekončí. Parametrizované vstupy ovlivňují chování šablony a na povolených místech i její obsah. Navíc vložená šablona je vkládána jako odkaz, což umožňuje promítnout změny na všech vložených místech. Správně vyznačený dokument není vše, a tak HTX Designer disponuje doplňkovým editorem CSS stylů. Každý styl má vazbu k elementům, které ovlivňuje, a tak je lze lehce dohledat. Protože tento modul je myšlen jako doplněk, není kromě syntaxe zajištěna další validita stylů z hlediska pravidel a jejich hodnot. Velice podobným způsobem, jakým je řešena správa stylů, probíhá údržba externích odkazů, jejichž spojování s příslušnými místy v dokumentech zaručuje aktuálnost dat a synchronizaci. Analogicky je postupováno u správy dalších souborů (např. obrázků), kde jsou opět zachovány vazby mezi souborem a elementem v dokumentu. Import těchto dat probíhá přímo přes rozhraní HTX Designeru. Soubory jsou pro přehlednost tříděny do několika složek.
Příklad 5.2.2.: Využití dědičnosti v hierarchii stránek /uvod = nadpis: Prodej elektroniky; Šablona: obchod /uvod/kontakty = Nadpis: Kontakty; (šablona se dědí z rodičovské stránky)
5.2.3.
Editor dokumentů
Editor dokumentů slouží k vlastní editaci stránek nebo šablon. Jeho rozhraní je rozčleněno do několika sekcí, jež umožňují manipulaci s elementem a podávají informace o jeho okolí, vlastních atributech a podelementech. Kontext elementu je zachycen ve dvou pohledech. První pohled ukazuje cestu dokumentem od kořene až k aktuálnímu elementu a druhý ve dvou fázích nad a pod jeho vlastnostmi zachycuje elementy na stejné úrovni, které mu předcházejí, resp. po něm následují. Mezi tyto kontextově-navigační prvky patří i výčet podelementů, tedy obsah, který element obaluje. Všechny elementy navigace jsou odkazovatelné, což znamená, že jednoduše můžeme na ně přecházet. Přesto pro komfort je ovládání kontextu doplněno o přesun na kořenový, rodičovský, předchozí a následující element.
16
Operace odstraňování, čištění, přesouvání, kopírování a vkládání podelementů jsou umístěny na ovládací liště pod editorem atributů. Všechny se vztahují vždy k aktuálnímu elementu a kromě operace odstraňování obsahují upřesňujícího průvodce. U přesouvání a kopírování vybíráme místo v dokumentu, na které má být přesouvaný či kopírovaný element vložen, u čištění vybíráme podelementy k odstranění a při vkládání v několika krocích vybereme umístění, počet a typ nově vkládaných elementů. Při vkládání nových elementů je rovněž uživatel vyzván k zadání povinných atributů. Poslední součástí rozhraní je editor atributů, který v závislosti na typu aktuálního elementu dává k dispozici příslušné ovládací prvky. Bližší charakteristikou těchto vlastností se budeme zabývat dále.
5.3. Elementy V této kapitole se blíže zaměříme na strukturu a typy logických jednotek tvořících dokument v HTX Designeru. Implementační pohled na uchovávání dat dokumentů v relační databázi je vysvětlen dále. Rozlišujeme dva režimy (stránkový a šablonový) určující možnosti použití jednotlivých stavebních prvků. Nebude-li uvedeno jinak, smí být jednotka vložena v libovolném režimu. Vyjdeme-li z terminologie XML, první velkou skupinu jednotek tvoří elementy patřící do jmenného prostoru použitého schémata. Až na výjimku týkající se viditelnosti atributů je struktura elementů analogická s XML, jak bylo popsáno výše. Viditelnost je prostředek rozšiřující možnosti tvorby šablon a přejímání informací z kontextu dané stránky: Fixní atribut – Hodnota atributu nemá zvláštní význam, je interpretována beze změn. Toto je obvyklé postavení atributu, jak jej známe z XML. Pravý význam ovšem spočívá v šablonovém režimu, ve kterém fixní atributy neovlivňují výsledné rozhraní šablony. Až na výjimky při vkládání odkazů jde také o jediný smysluplný typ pro tvorbu dokumentů ve stránkovém režimu. Vstupní atribut – Jeho hodnota má stejnou úlohu jako v předchozím případě s rozdílem, že takový atribut ovlivňuje rozhraní šablony a definuje v něm jednoduchý vstup s popiskem a výchozí hodnotou. Ve stránkovém režimu vstupní atributy nemají význam. Systémový atribut – Jeho hodnota je jménem kontextové proměnné, jež je vyčtena z prostředí a interpretována až v době prezentace. V rozhraní šablon se tyto vstupy projevují, mají ovšem spíše informativní charakter, aby uživatel byl vyrozuměn o vlastnostech stránky a dalších proměnných, jež má pro správnou funkci šablony nastavit. Ve stránkovém režimu se tyto atributy využívají pro vkládání odkazů, v šablonovém dovolují automatické vyplňování vstupů, což můžeme s výhodou uplatnit při tvorbě menu pomocí šablony, kdy kontextové proměnné s informacemi o postavení stránky, do které je šablona vložena, jsou generovány automaticky na základě stromové struktury projektu. Mimo rámec schémata určujícího skladbu dokumentu lze vkládat několik speciálních elementů, jež mají význam zejména v šablonovém režimu: Element šablona – Z implementačních důvodů je tento element omezen pouze na stránkový režim. Vložená šablona se chová jako standardní element, jednoduché vstupy jsou
17
editovatelné obdobným způsobem jako fixní atributy a blokové vstupy se zobrazují jako neměnný počet podelementů. Element vstup – Element označující blokové vstupy šablon, má popisek a podelementy sloužící jako výchozí hodnota vstupu. Ve stránkovém režimu tento element nemá význam. Element smyčka – V šablonovém režimu vyznačuje opakovatelný blok, který se generuje ve výsledku tolikrát, kolik je sad vstupů, což lze přirovnat k tabulce, kde buňky tvoří jednoduché vstupy (blokové z implementačních důvodů nejsou možné) a řádky celou sadu vstupů ohraničených tímto elementem. Smyčka má svůj popisek a název kontextové proměnné kontejneru. Smyčky s výhodou využijeme v kombinaci se systémovými vstupy při generování menu, nicméně i klasické vstupy lze takto spojit, HTX Designer potom v sekci pro editaci atributů při vložení šablony s kontejnerovým vstupem nabízí jednoduchého správce. Podmíněný element – U šablon tímto elementem můžeme dosáhnout rozhodování, zda vyznačený úsek bude ve stránce, kde je šablona použita, zahrnut či úplně vynechán. Podmíněný blok má svůj popisek a jednoduchou podmínku skládající se z odkazu na kontextovou proměnnou, z relačního operátoru rovnosti či nerovnosti a hodnoty, na kterou je kontextová proměnná testována. Element text- Ve stránkovém režimu odpovídá svou koncepcí CDATA sekcím v XML, u šablon má identické rozšíření viditelnosti s atributy tak, jak bylo popsáno výše. Obsahuje pouze bloky textu, žádné podelementy.
5.4. Generování prezentací Poslední fáze v procesu tvorby projektu je jeho vlastní zveřejnění, což v prostředí HTX Designeru znamená sesbírání dat z databáze a přeměnu do adresářové struktury přístupné přes protokol http. Transformace probíhá následovně: 1. Kontrola validity – Všechny stránky a šablony jsou postupně projity a testovány na vyplnění povinných atributů a výskyt prázdných elementů, jež jsou znakem nedokončeného výsledku (jejich bližší využití viz implementační detaily). 2. Export souborů do adresáře pro tyto účely - Soubory jsou vyzvednuty z databáze a roztříděny do složek tak, jak bylo zadáno ve správci souborů. 3. Generování stylů – Styly jsou generovány společně pro celý projekt do jednoho souboru, který se následně musí ke všem stránkám přilinkovat. 4. Následující body se provádějí tak dlouho, dokud nejsou zpracovány všechny stránky. 5. Založení stránky - Dle umístění ve stromové struktuře je určena cesta a název generované stránky. Dále na základě cesty stránkami ve stromu od kořene až po aktuální stránku se vytvoří kontextové prostředí proměnných. 6. XML transformace - Je postupně procházen strom dokumentu a exportovány do XML jednotlivé elementy z databáze a ukládány do souboru generované stránky. 7. Interpretace atributů - Je-li nalezen systémový atribut, doplní se hodnota kontextové proměnné dle jména v atributu. 8. Interpretace šablon – Je-li nalezena vložená šablona, započne se transformace dokumentu šablony a vstupy jsou vyplňovány na základě zadaných hodnot ve stránce či pod-
18
podle kontextových proměnných. Po průchodu šablonou se transformace vrací opět do stránky.
6. HTX Designer – implementace V této části se podíváme blíže na vybrané implementační provedení HTX Designeru, zejména pak na problém, jak uchovávat stromovou strukturu dokumentu v relační databázi.
6.1. Třídy Aplikace pro zapouzdření komunikace s databází používá sadu tříd, které jsou odvozeny od třídy HTX_DbSource. Tato třída zajišťuje udržení spojení s databází a nabízí pro svoje potomky řadu metod usnadňujících nejběžnější operace s databází jako např. vytváření tabulek a vkládání a úprava řádků. Téměř všechny také mají svou vlastní třídu pro generování výjimek při nenadálých chybách. Nad touto databázovou vrstvou se nalézá ještě třída starající se o formátování výstupu pro editor dokumentů A pro výsledné generování stránek. Třída k tomu používá spojování výstupů z obsluhy schémat a dokumentů, což zapříčiňuje explicitní definice elementů obsažených ve schématu, zatímco dokument nese informace pouze o struktuře vnořování elementů a hodnotách atributů.
6.2. Moduly Celý systém uživatelského rozhraní je rozčleněn na nejvyšší úrovni podle součástí z kapitoly 5.1., ve skutečnosti však na základě přijatých parametrů metodami GET či POST je zaveden příslušný modul řešící danou situaci. Prakticky každá stránka informující o nějaké události či žádající o vstup je samostatným modulem spadajícím pod hlavní skript. Každý ze skriptů ke správnému běhu používá společný zavaděč, který kromě načtení všech tříd HTX Designeru provede nastavení cest k nejpoužívanějším adresářům a inicializaci třídy s konfigurací databáze.
6.3. Uchovávání XML dokumentů v relační databázi Tato oblast je z implementačního hlediska nejzajímavější část aplikace, o čemž svědčí i způsob, kterým oproti ostatním databázovým třídám řeší třída pro manipulaci s dokumenty transfer dat. Metody nepracují přímo s dokumentem v databázi, nýbrž s jeho kopií v paměti a všechny změny se zapisují do logu, jehož položky jsou na konci práce promítnuty do databáze. Standardní či rozšiřující elementy mají v paměti podobu unifikovaných objektů lišících se pouze strukturou přidružených atributů. Objekt zahrnuje následující vlastnosti: Typ elementu (standardní XML, šablonový, smyčkový, vstupní, podmíněný a textový).
19
Id elementu. Pozici vzhledem k sourozeneckým elementům. Extenzi určující identifikaci ve schématu u XML elementů či šablonu u šablonových elementů. Odkaz na rodičovský element. Uspořádané pole odkazů na podelementy/potomky. Odkaz na objekt atributů, jehož struktura se odvíjí buď od definice ve schématu nebo od typu elementu a jeho vlastností. Implementace v relační databázi jako v našem případě v MySQL je strukturně velice podobná té v paměti s tím rozdílem, že kompaktnost celé datové struktury dokumentu se tříští na jednotlivé řádky tabulek a ani relační algebra neumožňuje takový SQL dotaz, jenž by aplikaci vrátil celý dokument, proto HTX Designer při zavádění dokumentu pracuje na dvou úrovních: Rekurzivní procházení tabulky s elementy a získávání sad sourozeneckých elementů. Rekurze spočívá v načítání elementů se společným rodičem, kterým se stávají postupně všechny načtené elementy. Individuálně pro každý načtený element jsou získávány atributy z příslušné tabulky. Každý typ elementu, jenž se může v dokumentu vyskytnout, má svou tabulku, kam se ukládají atributy. U standardních XML atributů je tabulka dokumentu a atributů ve vztahu 1:N, v ostatních případech 1:1.
7. Závěr – budoucí vývoj Jediným nedostatkem současné verze HTX Designeru je nutnost spoluúčasti uživatele při zabezpečování prezentovaných stránek. Kdybychom však ukládali generované stránky zpět do databáze a doplnili skriptovou sadu aplikace o prezentační systém zajišťující vyzvedávání dat a zasílání stránek uživateli, odpadla by i tato překážka v komfortním ovládání. Aby však bylo dosaženo dobře zapamatovatelných a dobře čitelných adres k jednotlivým stránkám, museli bychom zavést pravidla přepisování virtuálních adres k dokumentům na adresu prezentačního skriptu, kterému by přepisem byly předány parametry k zobrazení dané stránky. Uvedený postup umí řešit modul Mod_rewrite zahrnutý v distribuci WWW serveru Apache. S využitím integrovaného prezentačního systému jsme dále schopni zajistit plnou multi-uživatelskou podporu. Takto nastavená služba by se potom mohla pro nevidomé uživatele stát alternativou online webových systémů jako např. Googlepages nebo Geocities se všemi výhodami, které z centralizovaného řešení plynou – snadná dostupnost, sdílení schémat a šablon, společný postup ve vylepšování funkčnosti a efektivity a přitom bezpečnost a nezávislost jednotlivých uživatelských prezentací. Obzvláště možnosti sdílení nejrůznějších šablon a jejich množství by mohlo HTX Designer povýšit na sofistikovaný nástroj. Na závěr si můžeme dovolit říci, že by při dostatečném finančním a personálním krytí HTX Designer jako služba globálního charakteru našel své uplatnění mezi nevidomými celého světa a zacelil tak díru, jež na trhu s aplikacemi pro tvorbu webových stránek stále zeje, jak jsme se v textu této práce přesvědčili.
20
8. Použité zdroje Veškeré následující zdroje, ze kterých bylo čerpáno pro tuto práci, jsou HTML dokumenty a svým obsahem a umístěním v síti Internet platné ke dni 28.12.2006. Metodický návod verze 2.3 | Blind Friendly Web http://www.blindfriendly.cz/doc/bfw.php Introduction to Web Content Accessibility Guidelines 2.0 http://www.w3.org/TR/WCAG20/intro.html HTML editor - Wikipedia, the free encyclopedia http://en.wikipedia.org/wiki/HTML_editor Microsoft Active Accessibility - Wikipedia, the free encyclopedia http://en.wikipedia.org/wiki/Microsoft_Active_Accessibility WYSIWYM - Wikipedia, the free encyclopedia http://en.wikipedia.org/wiki/Wysiwym JAWS (screen reader) - Wikipedia, the free encyclopedia http://en.wikipedia.org/wiki/Job_Access_With_Speech
9. Příloha – datové struktury oddíly obsahují popis datových struktur, které HTX Designer používá k uchování dat v databázi MySQL. I když existují i vztahy mezi tabulkami v různých oddílech, nejsou uvedeny, protože ani nejnižší vrstva aplikace je nevyužívá.
9.1. Schémata 1. htx_scheme – tabulka základních informací o schématu: (ve vstahu 1:n se všemi níže uvedenými tabulkami kromě ‚htx_scheme_object_in_group‘) a. id – Identifikátor schémata b. login – Login zakladatele, pokud není vyplněno, jde o dostupné schéma pro všechny c. name – Jméno d. description – Bližší popis e. ver_maj – Číslo verze f. ver_min – Číslo podverze g. sgml_head – Identifikace dokumentu a procesní instrukce SGML h. xmlns – XML namespace použitých elementů ve schématu i. root – Identifikace kořenového elementu dokumentu 2. htx_scheme_attr – Tabulka atributů: (ve vstahu 1:1 s tabulkou ‚htx_scheme_object_in_group‘) a. id – Identifikátor atributu b. scheme – Identifikace schémata, do kterého atribut náleží
21
c. name – Jméno atributu ve výsledném kódu d. title – Alternativní název při editaci dokumentů e. type – Některý z datových typů: i. string – Obecný řetězec ii. bool – Logická hodnota iii. nmtoken – Klíčové slovo iv. nmtokens – Seznam klíčových slov oddělených čárkou v. id – Identifikátor vi. idref – Odkaz na identifikátor vii. idrefs – Seznam odkazů na identifikátory oddělených čárkou viii. charset – Kódová stránka ix. language – Jazyk x. number – Číslo xi. char – Písmeno xii. uri – Adresa odkazu xiii. urilist – Seznam adres odkazů oddělených čárkou xiv. datetime – Datum a čas xv. style_class – Stylová třída xvi. script – Kód skriptovacího jazyka (volání funkce/události) xvii. enum – Výčet možností anchor – Návěští xviii. f. restr – Omezení datového typu g. def_value – Výchozí hodnota 3. htx_scheme_group – Tabulka schémových skupin: (ve vztahu 1:n s tabulkou ‚htx_scheme_object_in_group‘) a. id – Identifikátor skupiny b. scheme – Identifikace schémata, do kterého skupina náleží c. g_type – Typ skupiny (atributová čí Klementová) d. title – Popisek skupiny e. s_type – Typ uspořádání (sekvence, množina, mix) 4. htx_scheme_element – Tabulka elementů ve schématu: (ve vztahu n:1 s tabulkami ‚htx_scheme_group‘ a ‚htx_scheme_attr‘) a. id – Identifikátor elementu b. scheme – Identifikace schémata, do kterého element náleží c. name – Jméno elementu ve výsledném kódu d. title – Alternativní název při editaci dokumentů e. attrs – Identifikace skupiny přidružených atributů f. content – Identifikace skupiny povoleného obsahu (podelementů) g. desc_a1 – Identifikace prvního popisného atributu pro vytváření charakteristiky elementu při editaci dokumentů (nulová hodnota značí obsah elementu) h. desc_a2 – Identifikace druhého (použije se při nevyplnění prvního) popisného atributu pro vytváření charakteristiky elementu při editaci dokumentů 5. htx_scheme_object_in_group – Tabulka objektů skupin: (ve vztahu 1:1 s tabulkou ‚htx_scheme_attr‘ a 1:n s tabulkami ‚htx_scheme_element‘ a ‚htx_scheme_group‘)
22
a. b. c. d. e.
grp – Identifikace skupiny, do které objekt náleží seq – Pořadí v sekvenci, jde-li o skupinu typu sekvence object – Identifikátor objektu o_type – Typ objektu (atribut, element, skupina) req – Povinnost výskytu objektu ve skupině
9.2. Projekty 1. htx_project – Tabulka základních informací o projektu: (ve vztahu 1:n se všemi níže uvedenými tabulkami kromě ‚htx_project_page_property‘, ‚htxt_style_rule‘ a ‚htx_object_refer‘) a. id – Identifikátor projektu b. login – Login vlastníka c. name - Jméno d. description – Bližší popis e. ver_maj – Číslo verze f. ver_min – Číslo podverze g. cr_date – Datum a čas založení h. up_date – Datum a čas poslední změny i. fresh – Příznak prezentace (je nastaven, pokud od posledního prezentování nedošlo ke změnám) j. scheme- Identifikace schémata, které je v projektu používáno ve všech dokumentech při editaci options – Bitové pole nastavení projektu 2. htx_project_page – Tabulka stromové struktury stránek projektu: (ve vztahu 1:n se sebou samou a tabulkou ‚htx_project_page_property‘) a. id – Identifikátor stránky b. parent – Identifikátor rodičovské stránky c. project – Identifikátor projektu, do kterého stránka náleží d. name – Jméno použité při pojmenovávání výsledných souborů e. description –Název stránky f. up_date – Datum a čas poslední změny g. root –Identifikace kořenového elementu stránky 3. htx_project_page_property – Tabulka vlastností stránek: a. page – Identifikátor stránky, ke které vlastnost náleží b. property – Název kontextové proměnné c. value - Hodnota 4. htx_template – Tabulka šablon: a. id – Identifikátor šablony b. login – Login vlastníka c. project – Identifikace projektu, do kterého šablona náleží d. name - Jméno e. description – Bližší popis f. ver_maj – Číslo verze
23
5.
6.
7.
8.
9.
g. ver_min – Číslo podverze h. root – Identifikace kořenového elementu šablony htx_style – Tabulka stylů: (ve vztahu 1:n s tabulkami ‚htx_object_refer‘ a ‚htx_style_rule‘) a. id – Identifikátor stylu b. project- Identifikace projektu, do kterého styl náleží c. description – Bližší popis stylu d. selector – Selektor stylu podle CSS htx_style_rule - Tabulka pravidel stylů: a. style – Identifikace stylu, ke kterému pravidlo náleží b. rule – Název pravidla podle CSS c. value – hodnota podle CSS htx_file – Tabulka souborů ke stažení v projektu: (ve vztahu 1:n s tabulkou ‚htx_object_refer‘) a. id – Identifikátor souboru b. project – Identifikace projektu, do kterého soubor náleží c. folder – Název složky, do které soubor náleží d. name - Jméno e. description – Bližší popis f. content – Samotný binární obsah g. up_date – Datum a čas poslední aktualizace htx_link – Tabulka externích odkazů v projektu: (ve vztahu 1:n s tabulkou ‚htx_object_refer‘) a. id – Identifikátor odkazu b. project – Identifikace projektu, do kterého odkaz náleží c. uri – Adresadescription d. description – Titulek odkazu e. content – Obsah (název) odkazu htx_Object_refer – Vazební tabulka mezi styly, soubory a externími odkazy a elementy používajícími tyto objekty: a. object – Identifikace objektu b. type- Typ objektu (styl, soubor, odkaz) c. element – Identifikace elementu, v kterém je objekt použit
9.3. Dokumenty 1. htx_element – Tabulka základních informací o elementu: (ve vztahu 1:n s tabulkami ‚htx_element_node_attr‘,‚htx_element_template_block_attr‘ a ‚htx_element_template_plain_attr‘ a ve vztahu 1:1 s ostatními níže uvedenými tabulkami) a. id – Identifikátor elementu b. parent – Identifikace rodiče elementu c. position – Pozice vzhledem k sourozeneckým elementům na stejné úrovni
24
2.
3.
4.
5.
6.
7.
8.
d. type – Typ elementu (standardní, šablonový, vstupní, smyčkový, podmíněný, textový a prázdný) e. extension – Identifikace šablony u šablonového elementu či elementu ve schématu u standardního elementu (u ostatních typů nemá význam) htx_element_node_attr – Tabulka hodnot atributů u standardních elementů: a. element – Identifikace elementu, ke kterému atribut náleží b. ATTR – Identifikace atributu ve schématu c. Type – Typ atributu (fixní, vstupní, systémový) d. content – Hodnota e. Description – Popis vstupu (nemá význam u fixních atributů) f. Extension – Identifikace šablony, jde-li o atribut v šabloně htx_element_template_block_attr – Tabulka hodnot blokových atributů u šablonových elementů: a. element – Identifikace elementu, ke kterému atribut náleží b. input – Identifikace vstupního elementu v šabloně c. content- Identifikace obsahu atributu HTX_element_template_plain_attr – Tabulka hodnot jednoduchých atributů u šablonových elementů: a. element – Identifikace elementu, ke kterému atribut náleží b. input – Identifikace elementu, který má daný atribut jako vstupní c. ATTR – Identifikace vstupního atributu ve schématu d. content – Hodnota atributu htx_element_input – Tabulka vstupních elementů: a. element – Identifikace elementu, ke kterému vlastnosti náleží b. template – Identifikace šablony, ve které se vstup nalézá c. description – Popisek htx_element_loop - - Tabulka smyčkových elementů: a. element – Identifikace elementu, ke kterému vlastnosti náleží b. name – Jméno kontejneru c. description - Popisek htx_element_defined – Tabulka podmíněných elementů: a. element – Identifikace elementu, ke kterému vlastnosti náleží b. property – Jméno kontextové proměnné c. relation – Relační operátor (= nebo <>) d. value – Testovaná hodnota e. description - Popisek htx_element_text – Tabulka textových elementů: a. element – Identifikace elementu, ke kterému vlastnosti náleží b. type – Typ (fixní, vstupní, systémový) c. content – Textový obsah d. description – Popisek, jde-li o vstup e. extension – Identifikace šablony, jde-li o šablonový vstup
25
