XBUP - Dokumentace: 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ů.

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.

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á.

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.

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.

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:

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ů

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.

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.

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.

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.

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:

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

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.

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).

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.

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

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

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ů

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
...

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

UBNatural - UpCount
UBPath - LinkPath

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
...

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

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á.

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.

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:

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.

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

Definice:

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.

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

Definice:

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.

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

Definice:

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.

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

Definice:

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

Definice:

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

Definice:

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

Definice:

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

Definice:

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

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.

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

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.

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

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.

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.

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.

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.

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.

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.

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ě.

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)

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