XBUP - Dokumentace: Úrovně protokolu

Zde uvedený nástin úrovní protokolu rozvádí úvahy o postupném přidávání nových vlastností a omezení do protokolu.

Navržená hierarchie úrovní je zatím dosti nejasná. Jednotlivé návrhy se překrývají a jejich lineární seřazení může býti dosti obtížné. V nejhorším případě by struktura úrovní tvořila svaz.

• Úroveň 0: Nejnižší úroveň specifikuje kódování čísel a stromovou organizace dat. Zřejmě bez kódování čísel by nebylo možné stromovou strukturu definovat. Také samotné kódování neurčuje protokol. Tyto dvě vlastnosti se zdají být dostačující na definici protokolu.
• Úroveň 1: Typ bloku a základní bloky pro definici dokumentu. Zřejmě základní bloky nejsou bez zavedení typu realizovatelné. Nicméně není jasné, zda je samotné zavedení typu bloku již rozšíření, které by stálo oproti úrovni 0 za zmínku. Spíše ne. Má však význam na této úrovni zavádět další vlastnosti?
• Úroveň 2: Prozatím je zde definován systém transformačních bloků. Nicméně tyto bloky už spíše vyžadují i existenci jazyka, který by umožnil definovat algoritmus, jehož provedením se daná transformace provede. Nicméně toto může zdá se fungovat i bez tohoto jazyka - uvidí se časem.

Všechny další úrovně jsou víceméně spekulativní a uteče ještě hodně vody než budu schopen rozhodnout, které řešení je to nejvhodnější. Tedy pokud na tom budu pracovat pořád jenom sám ;-)

Jedním z jistých rozšíření je zavedení typů atributů. Typ atributu je už zmiňován při zavádění typů bloků. Jsou to kromě standardních typů UBNatural, UBInteger a UBRatio například UBPointer, či vícepoložkové UBReal, UBVersion, UBList... Ačkoliv všechny atributy jsou kódovány jako hodnoty typu UBNumber, přesto se zdá vhodné nějakým způsobem umožnit rozlišovat, jaký význam má daná položka. Přesto typ atributu není významný pro základní validaci dokumentu, a proto asi nemá smysl jej zahrnout do úrovně 1.

Atributy v podstatě tvoří stromovou hierarchii (obdoba dědění objektových tříd). Například všechny atributy jsou typu UBNumber, některé atributy mají "rozhraní" pro nekonečné hodnoty atp. Kromě dědění by bylo vhodné zvážit, zda nemá smysl typy atributů prezentovat jako bloky určitého typu a zajistit jim tak ekvivalenci.

V případě atributů se dá také hovořit o jisté formě programování. Typ atributu v jisté formě tvoří jazyk, nebo také programový předpis, jakým je zkonstruován z jednodušších typů. Z pohledu while-programů jsou typy konstruovány pomocí sekvence a cyklu, jak konečného, tak nekonečného. Podobně v případě vícevýznamového typu se dá hovořit o podobnosti s paralelismem. Příkladem můžou být víceatributové typy UBReal a UBPath.

Je UBLength zároveň UBPath i UBCount? Problém dědění / zavedení rozhraní?

Především v případě, kdy blok obsahuje UBPointer (či UBList), by mělo být možné definovat, na jaký typ bloku může být odkazováno. To, že je odkazováno na blok, který patří do platného rozsahu typů ještě neznamená, že jej bude možné zpracovat. Samozřejmě se musí zohledňovat odkazovací bloky a i bloky transformační. Přesto je možné tuto variantu provozovat i bez transformačních bloků.

Mezi další jisté rozšíření patří realizace omezení rozsahu. Především pro použití na malých zařízeních je vhodné dostat soubor do omezených mezí. Řekněme, že je například potřeba omezit maximální velikost bloku na 64kB, aby ji bylo na malém zařízení možné zpracovat. Nebo případně omezit velikost bloku jako celku.

Příkladem může být omezení délky textu názvu souboru pro použití na malých zařízeních, nebo určení maximálního rozlišení obrázku.

Zřejmě by bylo vhodné umožnit realizaci přenášení atributů bloku. Například blok reprezentující seznam konkrétních položek by mohl potomkem bloku, který je seznamem libovolných položek. Tato vlastnost nemá opět vliv na konkrétní validitu dokumentu, ačkoliv lze validovat splnění podmínek dědičnosti. Případně uvádět bloky jako rozšíření jiných - nutné zpracování celé sekvence bloků.

Tato úroveň obsahuje navíc podporu pro instrukce zpracování dokumentů a jeho transformaci do jiných tvarů a instrukční předpisy pro platnost dokumentu.

Příkladem může být pokyn pro ignorování části dokumentu, nebo vložení dokumentu jiného z definovaného zdroje. Dále různé typy podmínek a testů, například na vlastnosti prostředí.

Jedná se o transformační bloky?

Touto vlastností je míněna obdoba vlastností CSS. Ty umožňují měnit implicitní hodnoty podstromů dokumentu. Například pro textový soubor by se dalo místo definice kódování pro každý textový řetězec toto definovat pro celé podstromy a pouze položky v odlišném kódování by měly toto definováno zvlášť. Pravděpodobně se spíše nejedná ve všech případech o kompresi, neboť náhradou těchto bloků by mohlo být možné například měnit vzhled dokumentu a podobně, tudíž by tyto definice implicitních hodnot mohly být zaměnitelné.

Například dvě varianty, první by pro danou skupinu a typ bloku, pro atribut na daném místě bloku, uváděla jeho implicitní hodnotu v případě neuvedení, nebo tak něco.

Druhá, zajímavější, určená především pro typ UBPointer, pracuje tak, že pro uvedený typ bloku a jeho atribut definuje existenci ukazatele na virtuální blok, na který sama ukazuje. Zřejmě tato varianta by byla realizována jako převodní transformační blok (strom na strom), kde by jeden vstup představoval seznam implicitních bloků a druhý strom do kterého by byly v případě jejich nepřítomnosti doplňovány.

Rozšíření o bloky, které by umožnily definovat význam bloku jiným než slovním popisem, například popisným algoritmem, nebo vazbou na aplikaci, která je schopna daný blok zobrazit v grafické podobě.

Tato vlastnost říká, zda zpracování daného bloku je nutné pro získání údajů z dokumentu jako celku. Například v případě obrázku, údaje o autorovi nejsou esenciální součástí dokumentu, i když mohou mít svůj podstatný význam. Tato vlastnost by mohla být realizována použitím definičních bloků na různých stupních zanoření, případně také uvedením významu ve specifikaci skupin. Tyto údaje by pak měli význam pro validitu použitelnosti dokumentu.