# XBUP - Dokumentace: Zavedení typů

### Úvod

Tento dokument je součástí dokumentace projektu eXtensible Binary Universal Protocol. Obsahuje popis zavedení typu bloků a atributů a způsob jejich použití.

O úroveň výše

### Obsah

1. Zavedení typů
1.1. Typ bloku
1.2. Typ dokumentu
1.3. Princip implicitní nuly
1.4. Skupiny bloků
1.5. Vazby mezi bloky
2. Typy atributů
2.1. Příklady typů atributů
2.1.1. Ukazatel
2.1.2. Logická hodnota
2.1.3. Zlomky
2.2. Posloupnosti atributů
2.2.1. Reálná a komplexní čísla
2.2.2. Verze bloku
2.2.3. Seznam
2.3. Dynamické posloupnosti atributů
2.3.1. Cesta
2.3.2. Odkaz
2.3.3. Seznam odkazovaných položek
2.4. Hierarchie typů atributů
3. Typový systém
3.1. Základní bloky
3.1.1. Deklarace dokumentu
3.1.2. Deklarace formátu
3.1.3. Deklarace skupiny
3.1.4. Deklarace bloku
3.1.5. Definice formátu
3.1.6. Definice skupiny
3.1.7. Definice bloku
3.1.8. Deklarace seznamu
3.1.8. Definice revizí
3.2. Deklarace typu atributů
3.2.1. Základní typy
3.2.2. Bloky složených typů
3.3. Deklarace dokumentu
3.3.1. Definice dokumentu
3.3.2. Příklady definic
4. Zpracování dokumentu
4.1. Zpracování deklarací
4.2. Validace dokumentu
4.2.1. Validita dokumentu
4.2.2. Kompatibilita dokumentu

### 1. Zavedení typů

V předchozích částech dokumentace bylo popsáno kódování čísel a stromová struktura bloků, kde bloky mají definovany posloupnosti atributů a podbloků. Dá se říci, že mezi atributy a podbloky existuje jistá dualita, protože atributy je možné vyjádřit jako podbloky, atributy jsou však omezeny na konečné hodnoty. Aby bylo možné data zpracovávat, je nutné definovat význam jednotlivých atributů a podbloků. Jelikož definice musí být konečná, je potřeba se omezit na konečný počet položek obého typu, a přesto umožnit realizovat spočetně velké posloupnosti atributů. Je také nutné zvážit, jak přesně bude význam definován a zvážit vztahy, jako je například generalizace/specializace. Je vhodné zvážit například:

- Jednotky - Je délka v metrech stejného typu jako délka ve stopách?
- Detailnost významu - Je délka v metrech stejného typu jako šířka v metrech?
- Vztahy hodnot - Je délka auta stejného typu jako délka letadla?

V prvním případě lze uvažovat tyto bloky za rozdílné, neboť používají odlišnou měrnou jednotku, ačkoliv v mnoha programovacích jazycích a také v databázích se přesto používá pouze základní vyjádření číselné hodnoty bez uvedení měrné jednotky. V druhém a třetím případě bude pravděpodobně vhodnější daný vztah vyjádřit spíše vazbou na nadobjekt, protože by se s takovým rozlišováním muselo definovat obrovské množství typů.

### 1.1. Typ bloku

V následující části bude zaveden způsob, jak rozpoznat význam dat obsažených v jednotlivých blocích. V úvahu opět připadá několik variant:

- Statická struktura bloků - Jednou z možností je definovat význam pomocí vhodné tabulky a následně přesně dodržet předepsanou strukturu. Tato varianta však jde proti požadavku rozšiřitelnosti, která by musela být řešena již na úrovni tabulky. Tato tabulka by však nemohla být popsána v samotném protokolu, protože by její rozšíření vyžadovalo, aby formát nebyl statický.
- Identifikace typu pomocí atributu - Další z variant předpokládá, že význam bloku bude definován pomocí atributů bloku. To by znamenalo, že pro datové bloky by nebylo možné definovat význam. Tento přístup umožňuje realizaci rozšiřování a nevyžaduje žádné speciální bloky. Tato varianta se zatím jeví jako nejvhodnější.
- Kombinovaný přístup - Je také možné kombinovat oba zmíněné způsoby. To by mohlo vést k snížení prostorových nároků. K dispozici jsou však také další prostředky, které by měli umožnit dosáhnout podobného snížení. (viz. komprimace a kondenzace)

Zřejmě nejvhodnější způsob je tedy identifikovat typ dat, které reprezentuje daný blok, pomocí jeho atributů. Jednotlivé typy bloků by mělo být možné podle významu rozdělit do skupin.

- Použití jediného atributu - Identifikace typu bloku by mohla být realizována tak, že by jednotlivé skupiny bloků byly postupně zařazovány do číselného rozsahu. Tato technika by však mohla narazit na problémy při změnách rozsahů. Například je nutné přepočítávání při přidání/odebrání nové skupiny, případně fragmentace.
- Použití dvou atributů - Mnohem vhodnější je použít dvě hodnoty pro kódování skupiny bloků a bloku z dané skupiny. To umožňuje přidávat a nahrazovat skupiny bez vzniku větších problémů a je tedy dostačující pro řešení rozšiřitelnosti.
- Použití více atributů - Více hodnot je naopak zbytečných a bylo by neefektivní uvádět u každého bloku úplnou cestu k jeho definici.

Zřejmě by tyto atributy měly být uváděny v bloku jako první. Pokud má tedy blok alespoň dva atributy, první dvě hodnoty jsou označovány jako UBBlockType a jsou tyto:

1 UBNatural - BlockGroup
2 UBNatural - BlockType

Bloky jsou podle typů organizovány do skupin (Groups) a hodnota BlockGroup určuje do které skupiny daný blok patří. Hodnota 0 znamená, že se jedná o základní blok, tedy blok, který je schopen program zpracovávající daný soubor vyhodnotit nativně vestavěnými prostředky. Hodnota BlockType pak určuje konkrétní typ bloku z dané skupiny. Povolené rozsahy hodnot a tedy význam skupin bloků, určuje definiční blok.

Pokud má blok méně než dva atributy, je možné zvolit více variant využití těchto nekompletních bloků:

- Použít principu implicitní nuly (viz.dále) a vše zpracovávat stejně (momentálně preferováno)
- Použít principu implicitní nuly na bloky včetně datového a pro něj vyhradit (0,0) - Je v rozporu s architekturou úrovní
- Využít jednoatributový blok pro jiné účely - Je možné blok použít i pro jiný, specifický účel - viz. následující odstavec

Speciálního případu jednoatributového bloku je možné využít více způsoby:

- Číselný blok - Hodnota atributu je typu UBNatural a nese blíže neurčený číselný údaj. To umožňuje kódovat samostatné číselné hodnoty pro potřeby jejich reprezentace mimo atributovou část a bez nutnosti uvedení typu. Na druhou stranu to může vést k tomu, že o významu této hodnoty nebudeme mít potřebné informace. Pro tento blok by mělo být definováno, v jakých případech jej lze použít. Případně je možné význam rozšířit na libovolný jednohodnotový typ UBNumber.
- Manipulátor skupin - Tento blok by mohl také vést k nějaké operaci se skupinou typů (první atribut je index typu). Příkladem by mohlo být uvolnění skupiny daného indexu, nebo posunutí indexu o danou hodnotu, případně UBInteger pro oba směry. Většinu těchto věcí je však možné řešit i jinými způsoby a navíc nejsou zrovna příliš často používány.
- Krátký skok - Blok by také mohl sloužit jako skok na blok daného indexu ve stejné oblasti.

### 1.2. Typ dokumentu

I pro rozpoznání dokumentu jako celku, potažmo typu datového proudu, je možné zvažovat několik variant:

- Identifikace pomocí přípony souboru - Tento klasický přístup se v mnoha ohledech neosvědčil. Přípony jsou sice dobře čitelné pro člověka, ale je obtížné je dodržovat. Přesto může být s výhodou použit pro základní rozlišení typu obsahu, alespoň u souborů.
- Identifikační řetězec nebo speciální struktura na začátku datového proudu - Další z méně vhodných způsobů je vyhrazením speciální oblasti na začátku souboru. Toto řešení je na první pohled nevhodné, protože jde proti principům protokolu.
- Identifikace pomocí kořenového bloku - Další možností je použití kořenového bloku jako identifikátoru významu souboru. Ačkoli bude obvykle soubor obsahovat více různých typů dat, některé budou pro daný soubor hlavní. Tento přístup je nejvhodnější, protože je v souladu se strukturou dokumentu.

Kromě vlastních bloků by měla být na začátku datového proudu posloupnost bitů, která by udávala způsob kódování. Jak bylo zmíněno v části věnující se kódování, je minimálně potřeba určit na začátku velikost použitého shluku.

Byte - ClusterSize = FEh

Aby bylo možné určit hodnotu ClusterSize, která může být obecně libovolná, je nutné ji uvést na začátek souboru, neboť se od ní odvíjí kódování následujících hodnot. Tato hodnota je z důvodu univerzálnosti kódována unárně. Výhodou je, že takto kódovaná hodnota má délku kódu odpovídající velikosti clusteru, obvykle ClusterSize = 7. Použití této hodnoty také mimo jiné vylučuje použití čistě unárního kódování.

Pro vývojové účely byla hlavička souboru obohacena ještě o několik dalších hodnot. Textové znaky jsou v hlavičce uvedeny z důvodu kompatibility se současnými operačními systémy a čitelné jsou pouze pro ClusterSize 8x + 7. Existence těchto hodnot je čistě technického rázu a mohou být v budoucnu vypuštěny.

UBNatural - ProtocolVersion = 00h
DWord(4xUBNatural) - ProtocolSignature = 58 42 00 XXh ("XB" + vývojová verze)

Verze protokolu 0 je rezervována pro vývojovou fázi protokolu. Vývojová verze pak stanovuje konkrétní organizaci struktury souboru a případné nekompatibilní změny ve struktuře se případně projeví ve změně právě této hodnoty.

Pokud se v souboru nevyskytují žádná další data, pak se soubor nazývá prázdný. V opačném případě jsou data zpracována jako jeden blok a data za tímto blokem jsou označena jako rozšiřující oblast. To má umožnit použití protokolu XBUP pro specifikaci typu bitového proudu obecně nekonečné délky. V mnoha operačních systémech se totiž nerozlišuje typ souboru podle názvu, ale podle obsahu, obvykle právě těchto prvních znaků. Hlavičku lze tedy interpretovat jako 32-bitové identifikační číslo a 16-bitovou verzi. Předpokládá se, že v konečné verzi bude hlavička souboru odlišná.

### 1.3. Princip implicitní nuly

Jednou ze zajímavých vlastností při interpretaci atributů bloku je možnost využít princip implicitní nuly, který říká, že pokud není atribut v atributové části přítomen, je to ekvivalentní stavu, jako by byl uveden a měl hodnotu nula. Tohoto principu lze využít pro zkrácení délky celého bloku, pokud atributy, které mají obvykle hodnotu 0 umístíme na konec atributové posloupnosti a při praktickém použití je pak bude možné vypouštět. Tento princip je tak možné uvést i jako argumentaci pro pořadí uvádění atributů bloků.

Technika také pomáhá s implementací kompatibility realizované jako rozšíření předchozí verze o nové atributy se speciálním významem. Také by bylo vhodné s tímto principem počítat při stanovování pravidel pro definici pořadí atributů.

V případě použití této techniky je možné zavést jednoznačný zápis, kdy se uvádí minimální počet atributů, tedy uvádí se pouze atributy až po poslední nenulový, za nímž následují pouze nulové hodnoty, které nejsou v bloku přítomny.

### 1.4. Skupiny bloků

Další z úvah se snaží vyřešit problém, jak organizovat skupiny.

- Statická varianta - Jednou z možností je určit pro každou skupinu její jednoznačné identifikační číslo a ty pak podle požadavků přidělovat. Tento přístup má řadu nevýhod, především by musela hodnoty přidělovat nějaká organizace. Možná úprava by mohla být v přidělování celých podmnožin rozsahů, například začínajících danou posloupností bitů a podobně. Nicméně je tato varianta stejně nevhodná jako použití jediného atributu pro určení typu bloku.
- Dynamická varianta - Jiným řešením je přidělovat rozsahy podle potřeby a definovat pouze jednu skupinu základních bloků, které primárně toto přidělování zajistí. Navíc kvůli proudovému zpracování by mělo být možné toto zajistit nejen na začátku datového proudu, ale i průběžně dle potřeby.
- Hybridní varianta - Kombinací předchozích dvou řešení je možné vytvořit strom dynamických deklarací, ve kterém by měli jednotlivé spravující organizace pevně definovány podstromy, jejichž správu by měly ve vlastní režii. Stromová architektura taktéž umožňuje organizovat typové definice do hierarchie podle dalších oblastí. Kromě takto definovaných skupin je nutné umožnit také definice nezávislé na daném stromovém katalogu, řešených například pomocí externích definic odkazovaných do veřejných zdrojů, nebo přímo přiložením k vlastnímu dokumentu. (preferováno)

Počet bloků ve skupině může být hypoteticky nekonečný. Přesto je vhodnější dodržovat konečný počet, především neukládat nevhodným způsobem hodnoty do nekonečných posloupností definic.

### 1.5. Vazby mezi bloky

Mezi bloky ve stromu je ze samotné definice stromu definován základní vztah rodič-potomek, který však nemusí plně pokrývat potřeby datových reprezentací. Důležitým aspektem je zde například dynamický kontext, který umožňuje zaměňovat různé bloky mezi sebou. Vazby bloku na jednotlivé datové položky (parametry) je pak možné řešit několika způsoby:

- Statické pořadí - Blok má (například v definici) uvedeno pevné pořadí parametrizovaných potomků.
- Rozpoznávání typu - Blok má definovány typy parametrizovaných potomků a prohledává své potomky na shodu.
- Úplné odkazování - Každý parametr bloku je odkazován pomocí relativní cesty - viz. dlouhá cesta.
- Přímé odkazování - Vazba na potomky může být realizovaná pomocí jednoho atributu jako index pořadí potomka. Odkaz na jiný blok v dokumentu by pak byl realizován samostatným blokem.
- Rozdílová metoda - Drobnou modifikací předchozí varianty je použití rozdílu od předcházejícího parametru. V implicitním tvaru by pak posloupnost odkazovaných bloků byla reprezentována jako sekvence hodnot 0, kterou by pak pomocí principu implicitní nuly bylo možné za určitých podmínek vynechat.

Jelikož je protokol v základu koncipován jako dynamický, vyžaduje statická varianta dynamiku na straně definic, která je však realizovatelná. Varianta používající rozpoznávání typu bloku by vedla k nutnosti prohledávat data a tedy je případně i cachovat, aby se k nim dalo vracet. Úplné či přímé odkazování zase zvyšují nároky na datovou kapacitu, ale především odporuje konceptu datové části jako blobu a zavádí odkazy, které nejsou nutné. Přímé odkazování by mohlo poskytnout potřebnou dynamiku za snad přijatelnou cenu jednoho atributu na parametr.

Jako řešení byla zvolená statická varianta, která nejlépe vyhovuje pojetí datové části bloku jako blobu. Pro potřebu vytváření seznamů bloků je však rozšířená o možnost použití atributu pro určení početu položek stejného typu v sekvenci podbloků. Změnu pořadí je možné realizovat odkazováním. Typy jednotlivých parametrů je opět možné řešit několika způsoby, např.:

- Množina povolených typů - Jednou z možností je definovat úplnou množinu povolených typů. Tento přístup ale není dostatečně dynamický.
- Právě jeden typ - Druhou možností je definovat pouze jeden typ a další typy pak zpracovávat pomocí transformací. (preferováno)

### 1.6. Revize

Pro zajištění zpětné/dopředné kompatibility je vhodné umožnit, aby specifikace podporovala přidávání nových definic při zachování stávajících. To je možné zajistit buď na vyšší úrovni protokolu, nebo definovat revize již na této úrovni. Technika revizí definuje, jak má být dokument zpracováván tak, aby aplikace dokázala zpracovávat i novější/starší revize.

Možné způsoby rozšíření definice typu bloku:

- Přidání nového atributu - Jednou z možností je povolit přidání nového atributu při zachování definice typu bloku. Nový atribut by pak musel při zpětné kompatibilitě zajišťovat ekvivalentní chování při nulové hodnotě.
- Přidání parametru (podbloku) - Obdobně je možné do definice zahrnout novou skupinu/blok/parametr.
- Rozšíření možných bloků parametr - Bude pravděpodobně definováno na další úrovni.
- Umožnění použití novějších revizí skupin/bloků/podbloků - Je možné rozšířit i stávající definice? Toto rozšíření zvyšuje nároky na zpracování dokumentu a požaduje kompletní znalost nových specifikací.
- Přidávání omezení - Další možnost je umožnit odebírat atributů

### 2. Typy atributů

Dalším krokem je zavedení typů atributů.

- Jeden atribut jako jedna hodnota - Jednou z možností je každou hodnotu převést právě na jeden atribut. Jelikož je možné takto převádět jak posloupnosti s konstantní délkou, tak proměnlivou, je toto řešení hypoteticky možné.
- Pouze konečné posloupnosti atributů - Omezením na konečné posloupnosti je možné dosáhnout pevného počtu atributů, nekonečné posloupnosti by pak bylo možné řešit jako podbloky, případně převedením na jediný atribut.
- Umožnit vícehodnotové typy - V tomto případě je nevýhodou to, že jeden typ může být posloupností více atributů, v případě UBPath dokonce proměnlivé velikosti. Přesto se zdá, že má tento přístup smysl.

V případě vícehodnotových atributů se nabízí otázka, jak řešit neomezeně velké posloupnosti. I zde je možné uvádět velikost zabraného prostoru, ale v tomto případě bude pravděpodobně uvedení počtu atributů vhodnější, také díky možnému konfliktu s principem implicitní nuly.

Nabízí se také možnost zavedení vhodné relevance mezi atributy a bloky, které představují právě jednu jejich hodnotu. V tomto srovnání by atribut představoval blok bez parametrů a typy atributů by mohli být představovány jako posloupnost takových bloků. Také je vhodné zvážit, zda je možné na atributy aplikovat stejnou stromovou hierarchii jako na bloky.

### 2.1. Příklady typů atributů

Mezi jednoduché atributy je možné zařadit posloupnosti hodnot UBNumber s pevně daným počtem prvků. Mezi základní a už zmíněné patří typy UBNatural, UBInteger a jejich varianty rozšířené o konstanty pro nekonečno a typ UBRatio. Tyto typy je pak možné rozšířit o význam definovaný specifikací, například pro použitou jednotku či jiný specifický význam.

### 2.1.1. Ukazatel

Tento typ (UBPointer) je základem řešení problému propojování dokumentu. Na rozdíl od XML není vhodné, aby vnitřní vazby v dokumentu byly řešeny prohledáváním poduzlů, neboť především s ohledem na možné transformace by mohl být problém rozpoznat konkrétní uzel. Je možné volit mezi více možnými řešeními:

- Použití pevného pořadí - jednou z možností je použití pevného pořadí závislých poduzlů. Toto řešení by nevyžadovalo žádné přidané atributy a potřebná informace by byla ukládána do popisu specifikace, což není příliš vhodné řešení. Navíc by vynechání poduzlu znamenalo nutnost použití nějakého druhu prázdného bloku.
- Použití odkazování na poduzly indexem - jiným možným řešením je vytvořit na každý požadovaný poduzel atribut, který by odkazoval na jeho index. Toto řešení by vyžadovalo znát dopředu indexy těchto položek a mohlo by působit potíže při proudovém generování dokumentu. Nulová hodnota by mohla představovat nepřítomnost požadovaného poduzlu. Dále by vznikla potřeba validovat existenci odkazovaného poduzlu. Nevýhodou je nutnost znát dopředu odpovídající index. Zatím byla vybrána právě tato varianta.
- Použití odkazování na poduzly pozicí - jinou variantou předchozího řešení je odkazovat se přímo polohou v souboru. Toto řešení vyžaduje dopřednou znalost velikosti podbloků, ačkoliv tu je možné relativně efektivně dopočítat. Zbytečně zvyšuje zátěž.
- Prohledávání poduzlů - je možné provádět prohledávání a vybrat jako požadovaný uzel první vhodný, případně zavést typování prvků pro případ transformace. Tento přístup by zvyšoval nároky na zpracovávání a mohl by způsobovat problémy v případě poduzlů stejných typů.
- Kombinované řešení - Možným řešením je také kombinace výše uvedených. Například použití UBENatural s konstantou pro nekonečno jako indikaci prohledávání místo odkazu na poduzel.

Zvolené řešení pro atribut typu UBPointer je realizováno následující hodnotou:

UBNatural - SubBlockIndex

Hodnota slouží pro odkazování se na vlastní podblok použitím hodnoty indexu jeho pořadí mezi podbloky. V případě, že odkazovaný blok není přítomen, je hlášena chyba WrongPointer. Bloky jsou indexovány od hodnoty 1 a hodnota 0 znamená prázdný ukazatel.

Alternativní možností je UBAccPointer, který je obdobný předchozí variantě, pouze v případě nulové hodnoty předpokládá polohu následující od poslední polohy UBAccPointer v tomto uzlu.

### 2.1.2. Logická hodnota

Jednoduchým omezením hodnoty UBNatural na hodnoty 0 a 1 vznikl typ UBBoolean pro ukládání logických hodnot.

Případně je možné použít hodnotu UBBitField, která vrací pole bitů pro bity hodnoty UBNatural.

### 2.1.3. Zlomek

Snahou je umožnit i realizaci zlomkových hodnot. Tyto hodnoty jsou však určeny výpočtem a proto by neměly být zahrnuty k základním typům.

Typ UBFraction slouží pro realizaci zlomku v intervalu <0,1> s nezápornými celočíselnými členy a bez dělení nulou. Z pohledu odpovídajících reálných hodnot má opakující se hodnoty. Hodnoty jsou ukládány jako posloupnost:

1/1, 1/2, 2/2, 1/3, 2/3, 3/3, 1/4, 2/4, 3/4, 4/4, ...
Sequence[n=1..][m=1..n](m/n)

Typ UBIntFraction je rozšířením pro celočíselné členy.

### 2.2. Posloupnosti atributů

Pro potřeby složitějších bloků bylo potřeba definovat určité konkrétní sekvence atributů vyjadřující složenou informaci. Jednotlivé položky mají vlastní pojmenování a tvoří určitou hierarchii.

Možností, jak se se skupinami atributů vypořádat je více:

- Ignorovat vícepoložkové typy a manipulovat pouze s jejich jednohodnotovými částmi - Problém nastává, pokud nedodržíme pořadí těchto částí, neboť nás k tomu nic nenutí. Stejně tak na abstraktní úrovni by nebyla manipulace s položkami tohoto typu výhodná.
- Zavést interpretaci sekvence atributů jako jediné položky už na této úrovni zároveň se zavedením typů
- Zavést pro vícehodnotové atributy novou úroveň, která je bude podporovat - pro zohlednění těchto skupin bude možná nutné definovat úroveň 2, která bude rozlišovat mezi posloupností atributů jako samostatných položek a skupin podle definice. Pro tyto skupiny je totiž odlišná validace a taktéž možnost neomezeně dlouhé skupiny atributů znamená, že se nelze obecně v bloku omezovat na neměnný konkrétní počet atributů.
- Sloučit vícehodnotové atributy do jediného pomocí interpretace posloupnosti - toto řešení porušuje přirozené kódování a mohlo by vést k velkým hodnotám.

Zda pro toto kódování zavést novou úroveň či případně některé věci sloučit do jedné úrovně zatím není zcela jasné a bude řešeno později. Prozatím je možné pokračovat i bez vyřešení tohoto problému.

Dále si uveďme si příklady některých vícehodnotových typů. Některé z nich byly zmíněny už v části kódování, případně v tomto dokumentu BlockType.

### 2.2.1. Reálná a komplexní čísla

Reálné číslo UBReal je popsáno už v části zabývající se kódováním:

UBInteger - Base
UBInteger - Mantis

Dostupné jsou také komplexní čísla:

UBReal - RealPart
UBReal - IrationalPart

Dále je možné použít rozšíření uvedených typů o konstanty pro nekonečno, tedy UBEReal, UBEComplex. Případně lze používat omezení uvedených typů na kladné, případně celočíselné varianty, např. UBPositiveReal, (UBCutInteger / UBTruncate).

### 2.2.2. Verze bloku

Bloky u nichž je vyžadována kompatibilita jsou řešeny pomocí následujícího typu UBVersion, který je posloupností dvou atributů pro určení verze bloku:

UBNatural - MajorVersion
UBNatural - MinorVersion

Pokud jsou obě hodnoty nulové, uvažuje se verze bloku jako neuvedená. Hodnota MajorVersion = 0 představuje testovací verzi. Pro rozšířenou verzi UBVersionExt může obvykle následovat atribut:

UBPointer - AlternativeBlock

Což je odkaz na jiné bloky stejného typu ale s jinou verzí. Pro realizaci verze je stejně jako v případě potřeba dvě hodnoty. První z hodnot určuje zpětnou kompatibilitu a druhá dopřednou. Pro stejnou hodnotou MajorVersion totiž musí být zaručena s rostoucí hodnotou MinorVersion to, že posloupnost atributů je pouze rozšiřována o nové položky.

### 2.2.3. Seznam

Seznam UBList je struktura definující konečný seznam atributů:

UBNatural - ItemsCount
UBNumber - Value 1
..
UBNumber - Value n

Případně umožnit UBENatural ItemsCount?

### 2.3. Dynamické posloupnosti atributů

Ukázalo se být vhodné, umožnit také vytváření typů položek reprezentovaných pomocí proměnlivého počtu atributů. Realizace těchto posloupností je poněkud problematická:

- Určení typu atributu vyžaduje zjištění obsahu některých atributů
- Změna hodnot některých atributů mění význam jiných atributů

### 2.3.1. Cesta

Tento typ, pod názvem UBPath, je definován jako posloupnost hodnot typu UBNatural, určený zde především pro realizaci cesty ve stromu.

UBNatural - PathCount
UBPointer - Path0Node
UBPointer - Path1Node
UBPointer - Path2Node
...

### 2.3.2. Link

S využitím předchozího typu lze zkonstruovat odkaz UBLink na jiný blok v dokumentu.

UBNatural - UpCount
UBPath - LinkPath

### 2.3.3. Seznam odkazovaných položek

Následující typ UBPointerList je obdobou typu UBList, jednotlivé položky seznamu jsou však odkazovány pomocí hodnot typu UBPointer, což umožňuje jejich uvádění v jiném pořadí, než v indexem definovaném. Také je takto možné mezi jednotlivé položky vkládat další bloky.

UBNatural - ItemsCount
UBPointer - Item0
UBPointer - Item1
UBPointer - Item2
...

### 2.4. Hierarchie typů atributů

Specifikace bloku z předchozí úrovně dokumentu může definovat seznam odkazující na bloky reprezentující jednotlivé atributy. Blok reprezentující atribut by měl být následující, umožňující specifikovat typ atributu.

Atributy jsou definovány stejně jako bloky ve stromové struktuře. Kořenem typu atributů je UBNumber. Současná navrhovaná struktura typů atributů je následující:

- UBNumber
  - UBNatural
    - UBPointer
  - UBInteger
  - UBRatio
  - UBBoolean
  - UBSequence
    - UBVersion
    - UBReal
    - UBList
    - UBPath
      - UBPointerList

### 3. Typový systém

Aktuálně zvolená varianta používá pro definici typu tzv. definiční seznam, který tvoří seznam položek na něž jsou použity dva možné druhy operací, a to připojení (JOIN) a přidání (CONSIST), přičemž přidání přidá na konec další položku podtypu, kdežto připojení přípojí všechny položky odkazované definice stejného typu. Tyto seznamy mezi sebou propojují položky tří typů definující formát, skupinu a blok dokumentu. Každá z těchto definic má také seznam revizí definující počet použitých vazeb. Pro specifikaci bloku jsou navíc přidány operace pro konečný a nekonečný seznam.

Kromě toho jsou v definičním seznamu bloku další vyjímky:

- Atribut - Připojení právě jednoho obecného atributu. Řešeno jako operace JOIN na neuvedenou položku
- Datový blok - Přidání datového bloku. Řešeno jako operace CONSIST na neuvedenou položku
- Obecný blok - Přidání obecného bloku. Řešeno jako nedefinovaná operace
- Konečný seznam - Připojení seznamu obecných bloků. Řešeno jako samostatná operace typu JOIN
- Nekonečný seznam - Přidání potenciálně nekonečného seznamu bloků. Řešeno jako samostatná operace typu CONSIST

Definice bloku tak může zahrnout jak atributy, tak parametry. To umožňuje částečně řešit dualitu mezi atributy a podbloky, kdy je pod jedním typem definován seznam atributů a zároveň blok, který tyto atributy používá.

Definice typového systému jsou uloženy v tzv. katalogu typů, případně je možné použít vlastní definice pomocí vestavěných základních bloků a později by mělo být možné připojovat definice z libovolného zdroje.

Následující ER diagram ukazuje schéma typu v catalogu typů, včetně umístění definic do stromu kategorií:

Zdrojový soubor diagramu diagram4.dia

Jako další alternativy připadá v úvahu definovat oba seznamy zvlášť a případné vazby vyjádřit jiným způsobem. ...

Máme tedy k dispozici bloky, u nichž je potřeba odlišit, co který typ bloku znamená. Také bylo zmíněno, že typ dokumentu lze zjistit z obsahu kořenového bloku. Nabízí se opět několik možností, jak typ bloku interpretovat:

- Použít statickou tabulku - Jednou z variant je definovat tabulku skupin i bloků a ty pak přidělovat zájemcům. Toto řešení je nevhodné a vedlo by k postupnému nárůstu hodnot, zastarávání a dalším negativním rysům.
- Deklarovat význam dynamicky - Vhodnější variantou je deklarovat pro daný dokument význam těchto hodnot dynamicky podle potřeby.

Zřejmě pro specifikaci dokumentu je nutné, aby existovali pevně stanovené bloky, které by umožňovali minimálně definovat význam dalších bloků v dokumentu. Pro tyto bloky je vyhrazena hodnota BlockGroup = 0 a plná podpora těchto bloků je vyžadována pro všechny aplikace podporující úroveň 1 a vyšší protokolu XBUP.

Na rozvržení základních bloků jsou stanoveny obdobné požadavky jako na strukturu:

- Rozpoznání typu proudu
  Primární obsah souboru by mělo být možné rozpoznat přečtením začátku souboru. Už z prvních bloků, by mělo být možné zjistit, jaký typ dat je základním obsahem dokumentu.
- Rozpoznání typu podstromu
  I u souboru u kterého není rozpoznán typ hlavičky, by mělo být možné rozpoznat typ některých podstromů, které nesou samostatné nezávislé, většinou pomocné data.
- Rozšiřitelnost
  I na tuto část se vztahuje požadavek rozšiřitelnosti. Samotná možnost rozšiřování skupin bloku není dostačující a mělo by být možné přidávat další typy bloků i v hlubších úrovních stromu.
- Dostupnost definice dokumentu
  Deklaraci dokumentu by mělo být možné přiložit jako součást dokumentu, či na veřejně dostupném zdroji, tedy v současné době především na internetu.

Kromě toho je pro bloky potřeba zavést definici seznamu a to jak pro seznam atributů, tak seznam parametrů. Je potřeba zvážit následující aspekty:

- Nekonečný seznam parametrů
  Je vhodné umožnit definici nekonečného seznamu parametrů pro zpracování nekonečných proudů bloků. U nekonečného seznamu atributů a bloků by bylo obtížné zaručit stejný počet obou, nekonečný seznam atributů obecně. Je však nutné definovat způsob ukončení takového seznamu, standardně koncem bloku. Tím by se však znepřístupnili veškeré další atributy a parametry bloku. Alternativně je možné používat ukončení speciálním blokem, například prázdným datovým blokem. Místo nekonečných seznamů je také možné použít techniku řetězených bloků. Zvoleno používat + ukončení i prázdným blokem.
- Vícerozměrné seznamy
  Umožnit vícerozměrné seznamy, případně povolit pouze seznamy seznamů. Umožnit nekonečné vícerozměrné seznamy - zvoleno pouze vícerozměrné konečné seznamy jednorozměrných potenciálně nekonečných seznamů.

### 3.1. Základní bloky

Základní bloky by měly primárně umožnit vytvářet definice typů a základní konstrukce umožňující jejich adresování. Jelikož typy bloků jsou dány dynamicky, je potřeba umožnit definici skupin a bloků také v dokumentu. Pro tento účel je vhodné použít skupinu bloků, která by umožňovala deklarovat význam dalších skupin a typů bloků dokumentu a volitelně používat vestavěnou definici či katalog. Kromě toho by měl existovat kořenový blok dokumentu určující co daný dokument obsahuje za data. Vhodným řešením tak je použít kořenový blok dokumentu pro deklaraci formátu, která by obsahovala jako jednu z položek hlavní blok jakožto kořenový blok vlastních dat dokumentu. Speficikace může být interní i externí, a to i zároveň, přičemž interní definice zahrnutá přímo do dokumentu má přednost před katalogem.

Základní bloky by tak měly pokrýt definice typového systému. V katalogu jsou definovány ve skupině Basic (0) / Basic (0) a implicitně vždy definovány pro skupinu 0, přičemž blok s typem (0,0) je vyhrazen jakožto tzv. neznámý blok a tedy zátoveň také jako datový blok díky možnému použití principu implicitní nuly. Základní bloky tak začínají až od hodnoty 1.

### 3.1.1. Deklarace

Block: Basic (0) / Declaration (1)

Deklarační blok určuje povolené rozmezí skupin a typy bloků. Tento blok by se měl nacházet na začátku každého souboru, pokud se aplikace dopředu nedomluvili na pevném významu.

Definice:

Join GroupsReserved (UBNatural) - Počet rezervovaných skupin
Join PreserveCount (UBNatural) - Počet skupin, jejichž předchozí definice má být zachována
Consist FormatDeclaration - Deklarace formátu
Any DocumentRoot - Kořenový blok dokumentu
List Attachements - Seznam dalších bloků

U podbloků tohoto bloku je povolen rozsah hodnot skupin v intervalu PreserveCount + 1 .. PreserveCount + GroupsReserved + 1. Pokud je hodnota PreserveCount = 0, bere se nejvyšší dosud rezervovaný blok v aktuálním nebo rodičovských blocích + 1. Pro veškeré hodnoty rovny nule a aplikaci pravidla odřezávání nul tento blok koliduje s datovým blokem.

### 3.1.2. Deklarace formátu

Block: Basic (0) / FormatDeclaration (2)

Tento základní blok reprezentuje deklaraci formátu. Určuje posloupnost skupin a případně jejich definici.

Definice:

Join GroupsLimit (UBNatural) - Maximální povolená hodnota skupiny pro typy bloku
Join FormatSpecCatalogPath (UBPath) - Specifikace formátu definovaná cestou v katalogu
Join Revision (UBNatural) - Číslo revize specifikace
List GroupDeclaration - Deklarace skupiny
List FormatDefinition - Definice formátu
List Revision - Definice revize specifikace

Seznam GroupDeclaration určuje posloupnost skupin formátu, zatímco FormatDefinition definuje posloupnost operací Join/Consist. Spolu pak ještě se seznamem revizí definují specifikaci formátu.

### 3.1.3. Deklarace skupiny

Block: Basic (0) / GroupDeclaration (3)

Tento základní blok reprezentuje deklaraci skupiny. Určuje posloupnost bloků a případně jejich definici.

Definice:

Join BlocksLimit (UBNatural) - Maximální povolená hodnota bloku pro typy bloku
Join GroupSpecCatalogPath (UBPath) - Specifikace skupiny definovaná cestou v katalogu
Join Revision (UBNatural) - Číslo revize specifikace
List BlockDeclaration - Deklarace bloku
List GroupDefinition - Definice skupiny
List Revision - Definice revize specifikace

Seznam BlockDeclaration určuje posloupnost bloků ve skupině, zatímco GroupDefinition definuje posloupnost operací Join/Consist. Spolu pak ještě se seznamem revizí definují specifikaci skupiny.

### 3.1.4. Deklarace bloku

Block: Basic (0) / BlockDeclaration (4)

Definice bloku je dvouúrovňová, neboť je potřeba definovat jak atributy, tak podbloky.

Definice:

Join AttributesLimit (UBNatural) - Maximální počet platných atributů (zahrnuje seznamy)
Join ParametersLimit (UBNatural) - Maximální počet platných parametrů (zahrnuje seznamy)
Join BlockSpecCatalogPath (UBPath) - Specifikace bloku definovaná cestou v katalogu
Join Revision (UBNatural) - Číslo revize specifikace
List ListDeclaration
List BlockDeclaration
List BlockDefinition
List Revision - Definice revize specifikace

Seznam BlockDeclaration určuje posloupnost bloků ve skupině, zatímco BlockDefinition definuje posloupnost operací Join/Consist, případně ListJoin/ListConsist. Spolu pak ještě se seznamem revizí definují specifikaci bloku.

### 3.1.5. Definice formátu

Block: Basic (0) / FormatDefinition (5)

Definice formátu jakožto posloupnosti ke sloučení.

Definice:

Join ConsistSkip (UBNatural) - Počet podpoložek před začátkem sloučení
Join JoinCount (UBNatural) - Počet spojených položek
Consist FormatDeclaration - Specifikace formátu

### 3.1.6. Definice skupiny

Block: Basic (0) / GroupDefinition (6)

Konstruktor skupin jakožto posloupnosti ke sloučení.

Definice:

Join ConsistSkip (UBNatural) - Počet podpoložek před začátkem sloučení
Join JoinCount (UBNatural) - Počet spojených položek
Consist GroupDeclaration - Specifikace skupiny

### 3.1.7. Definice bloku

Block: Basic (0) / BlockDefinition (7)

Konstruktor bloku jakožto posloupnosti ke sloučení.

Definice:

Join ConsistSkip (UBNatural) - Počet podpoložek před začátkem sloučení
List ListDeclaration - Deklarace seznamu
Join JoinCount (UBNatural) - Počet spojených položek
Join IsList (UBBoolean) - Indikace listového sloučení
Consist BlockDeclaration - Specifikace bloku

### 3.1.8. Definice seznamu

Block: Basic (0) / ListDefinition (8)

Tento specifikační blok určuje potenciálně nekonečné seznamy parametrů.

Definice:

Join ConsistSkip (UBNatural) - Počet podpoložek před začátkem sloučení

### 3.1.9. Definice revizí

Block: Basic (0) / RevisionDefinition (9)

Pro definici revizí je potřeba použít samostatný seznam.

Definice:

Join RevisionCount (UBNatural) - Počet položek revize

Todo: Chybí argumentace pořadí základních bloků, jejich atributů atp.

### 3.2. Specifikace typu atributů

Katalog kromě specifikace počtu atributů a podbloků bloku definuje také typ těchto položek (možná bude přesunuto na úroveň 2). Tato však bude Jako rozšíření první úrovně je možné zavést typování atributů. V počáteční fázi bude význam atributů definován pomocí textového popisu a později bude rozšířen o algoritmickou definici, případně založenou na matematických principech.

### 3.2.2. Základní typy

Základní typy odpovídají výše uváděným typům atributů.

### 3.2.2. Bloky složených typů

Tato skupina bloků je potřebná pro konstrukci složitějších bloků, které se skládají z více jednodušších částí. Jedná se především o sekvenci a kolekci. Využití lze najít například už při specifikaci dokumentu pro seznamy bloků a skupin.

### 3.3. Specifikace dokumentu

Zde uveďme některé z možných způsobů jak definovat typ bloků v dokumentu. (zastaralé)

### 3.3.1. Definice dokumentu

Definice dokumentu je samostatný dokument, určující povolené rozsahy hodnot skupiny a typu bloku. V případě této specifikace ukazují hodnoty GroupListPointer a DocumentRootPointer na stejný blok.

### 3.3.2. Příklady definic

Definice se liší především v tom, jaká část je dostupná externě.

- Úplná definice - pokud je to vhodné, je možné uvést veškeré bloky specifikující typ bloků dokumentu a jejich rozsah atributů.
  Rezervace skupin
  Seznam
  Specifikace skupiny
  Seznam
  Specifikace bloku
  ...
  Specifikace bloku
  Seznam (...)
  ...
  Seznam (...)
  Specifikace skupiny (...)
  ...
  Specifikace skupiny (...)
- Minimální definice - příkladem případu na opačném konci je uvedení minimálního množství údajů a odkazování zbývajících informací z internetového katalogu.
  Rezervace skupin
  Odkaz
  Kořen internetového katalogu
- Standardní definice - pokud je to vhodné, je možné uvést i detailnější informace, než jsou ty minimální. To je vhodné například pro dokumenty u nichž se předpokládá, že nebude trvale k dispozici internetové centrum, nebo v případě jednoúčelových formátů.
  Rezervace skupin
  Seznam
  Odkaz
  Kořen internetového katalogu
  ...
  Odkaz
  Kořen internetového katalogu

Specifikace je tedy možné kombinovat a dle potřeby specifikovat na nižších úrovních.
TODO: Specifikace s alternativním tvarem i odkazem do katalogu.

### 4. Zpracování dokumentu

Následuje popis způsobu, jak se vypořádat se specifikací dokumentu. Jedná především o techniky pro provádění kontroly a propojování specifikací do sekvence.

### 4.1. Zpracování specifikací

Je potřeba zpracovávat vhodným způsobem definované specifikace. Ačkoliv je možné držet si potřebné tabulky pro každý blok, bylo by to dosti neefektivní. Následuje nástin doporučovaného způsobu.

### 4.1.1. Aktuální specifikace

Aktuální specifikace udržuje hodnoty indexů do katalogů pro aktuálně zpracovávaný prvek a drží si seznam platných rozsahů skupin pro nižší úrovně. V případě, že chceme zpracovat jiný blok dokumentu, stoupáme ve stromu tak daleko, jak je to nutné a umazáváme skupiny podle tabulky. Poté procházíme bloky na cestě k požadovanému uzlu a zpracováváme specifikační bloky.

### 4.1.2. Předzpracované specifikace

Projdeme dokument do hloubky a vypracujeme specifikační tabulku pro každý specifikační blok. Pro aktuální blok opět držíme kopii specifikace. Při zpracování jiného bloku projdeme jeho předky, dokud nenarazíme na specifikační blok, jehož tabulku použijeme.

### 4.2. Validace dokumentu

Podle uvedených pravidel pro jednotlivé úrovně je vhodné kontrolovat, zda jsou požadovaná omezení dodržována. K porušení může dojít jak chybou aplikace, tak poškozením souboru. Kontrola dokumentu je dělena na pravidla pro určení platnosti a pro určení kompatibility dokumentu. Zatímco platnost říká, zda je soubor správně napsán a tedy je použitelný pro práci, kontrolou kompatibility je možné určit, zda daný dokument je použitelný pro danou konkrétní aplikaci. V případě protokolu XBUP tvoří validace obdobnou hierarchii, jako úrovně.

### 4.2.1. Validita dokumentu

Dokument je platný (validní) pokud je správně utvořen a jsou správně definovány všechny typy bloků a jejich atributy. To přesněji znamená:

- Dokument je správně utvořen, bylo definováno na úrovni 0
- Hodnota BlockGroup každého bloku nepřesahuje ve svém kontextu hodnotu v povoleném rozsahu (WrongGroup)
- Hodnota BlockType každého bloku nepřesahuje povolený rozsah hodnot ve své skupine (WrongType)
- Počet atributů každého bloku není větší, než rozsahem povolený počet (TooManyAttributes)

### 4.2.2. Kompatibilita dokumentu

Kompatibilita je vlastnost dokumentu, říkající, že tento dokument je daná aplikace schopna zpracovávat. Aplikace je kompatibilní pokud:

- Hlavní verze dokumentu je v množině podporovaných hodnot
- Hodnota vedlejší verze je stejná nebo větší než hodnota podporované daného bloku

Todo:
- definovat typ položek včetně např. UBPointer na další úrovni + relevantní typy odkazovaných podbloků
- argumentace pro pořadí základních bloků
- argumentace pro pořadí atributů
- blok pro definici dodatečných dat se zachováním významu

Homepage: http://xbup.sf.net
License: GNU Free Documentation License (FDL)
Latest update: 2009-08-01