XBUP - Dokumentace: Organizace proudu dat

V případě specifikace struktury datového proudu byl postup návrhu ještě méně přímočarý než u kódování čísel. Doposud nebyla stanovena konečná varianta a jsou zvažovány alternativní řešení. Základem zůstává blokově-stromová struktura.

Z cílů, stanovených pro tento projekt, se struktury datového proudu týká většina. Především by měla být realizována kompatibilita a rozšiřitelnost.

Stanovené požadavky:

• Organizace bitů po kvantech
  Stejně jako u kódování čísel, i zde je požadováno, aby jednotlivé prvky dat byly adresovatelné po n-ticích bitů.
   
• Realizace neomezeně velké posloupnosti dat
  Tento požadavek, podobně jako u požadavku pro kódování neomezeně velkého čísla, se snaží vynutit to, aby bylo možné kódovat neomezeně velkou posloupnost bitů dat. Tyto data mohou mít pak libovolný význam, obvykle však specifikovaný metadaty.
   
• Zavedení normálního tvaru
  Především kvůli možnosti porovnání dvou souborů je vhodné, aby bylo možné převést datový proud do nějaké výchozí standardní varianty, neobsahující kompresi, ani šifrování.
   
• Zpracovatelnost
  Pokud chceme zpracovat data realizované pomocí protokolu XBUP, mělo by být možné snadno přeskakovat části, které nejsou pro naše momentální potřeby relevantní.
   
• Minimalizace
  Blok by měl v základní variantě obsahovat co nejméně informace, nejlépe pouze nutné údaje. Další atributy by měly být nepovinné, případně by se rozšiřovalo přidáváním nových podbloků. Toto vylučuje například použití povinných kontrolních součtů, jako je například CRC, nebo MD5 Hash. Stejně tak je zakázán princip rezervování prostoru pro pozdější využití. I tak formát nebude ve svém standardním tvaru schopen co do velikosti konkurovat současným rozšířenějším specializovaným binárním formátům.
   

Jistě bude potřeba ukládat posloupnost hodnot v kódování UBNumber. Tuto posloupnost je potřeba nějak omezit. V úvahu připadají například tyto možnosti:

• Použití pevného počtu položek
  Jednou z možností je použití pevně definované posloupnosti položek s definovaným významem.
   
• Použití zarážky
  Posloupnost hodnot je zakončena speciálním terminálním symbolem.
   
• Uvedení počtu položek
  Na začátku posloupnosti je uvedena hodnota, uvádějící počet následujících položek, které patří do posloupnosti.
   
• Uvedení délky použitého prostoru
  Na začátku posloupnosti se uvede velikost prostoru, který zabírají dané položky.
   

První přístup by znamenal například to, že by blok začínal například jednou či dvěma položkami definujícími typ a jednou položkou určující délku následného datového blobu. Tato velice jednoduchá koncepce je například používána v EBML. Nevýhodou a zároveň výhodou je, že každá hodnota by musela být obalena samostatným blokem. Mezi nevýhody tohoto jinak plnohodnotného řešení patří:

• Zjištění informací o bloku vyžaduje zpracování neznámeho počtu podbloků (stromu)
• Obalování hodnot typu UBNumber je redundantní, neboť tyto hodnoty obsahují délku už samy o sobě

Ačkoliv proti tomuto konceptu nejsou momentálně k dispozici žádná podložené argumenty, přesto byl odložen pro pozdější přehodnocení.

Nevýhodou druhého přístupu je nutnost přečtení všech položek i v případě, že je chceme pouze přeskočit. Zřejmě nejvhodnější bude třetí z uvedených variant, která umožňuje snadné přeskočení celé posloupnosti, pokud nemáme o její přečtení zájem. Zabraný prostor je nejlépe uvést jako počet obsazených shluků dat. Zarážka je v tomto případě nepoužitelná, neboť jsou využity všechny kódy a bylo by nutné je nějak omezit. Věřím, že nekonečná posloupnost těchto hodnot půjde řešit i jiným způsobem.

Pro ukládání dat potřebujeme i posloupnost bitů obecně libovolné délky. Tuto posloupnost můžeme určit pomocí jedné hodnoty, určující délku, nebo použít zarážku. Nakonec jsem zvolil určení délky posloupnosti pomocí hodnoty typu UBENatural, kde konstanta pro nekonečno značí ukončení zarážkou. Tuto možnost je vhodné využívat především v případě, kdy neznáme budoucí délku bitové posloupnosti. Jiný způsob by mohlo být použití hodnoty nula pro data ukončeny zarážkou. Prázdný blok by pak tvořila samotná zarážka.

Posloupnosti hodnot je vhodné organizovat do bloků. Kromě vztahu "býti podblokem", můžou mezi bloky existovat i jiné druhy vztahů. Tyto vztahy je možné opět vyjádřit několika způsoby:

• Indexovaná posloupnost bloků
  Bloky jsou uvedeny jeden za druhým a vztahy mezi nimi jsou realizovány pomocí indexů. Tento přístup vyžaduje velkou režii při vyhledávání souvislostí mezi bloky, nutnost procházet všechny bloky, nebo zavádět obousměrné vazby mezi bloky.
   
• Stromová struktura
  Tento typ organizace dat umožňuje vyjádřit závislost mezi bloky pomocí vlastnosti "býti podblokem". Nakonec bylo vybráno právě toto řešení, neboť umožňuje vyjádřit dostatečnou závislost při zachování dobré zpracovatelnosti.
   
• Pevně stanovená posloupnost bloků
  Každá reprezentace dat by také mohla být stanovena pevnou posloupností jednoho, či několika bloků, to by však vyloučilo mnohé z požadovaných vlastností, znemožňovalo rozšiřitelnost a především by to mohlo způsobovat rozpory mezi realizací a logickou strukturou dat.
   

Zřejmě musí existovat blok umožňující ukládat obecně libovolnou posloupnost bitů, která může být případně interpretována jako podblok, nebo lépe posloupnost podbloků. Pokud by takový blok neexistoval, musela by být vždy dopředu známa velikost všech podbloků, což znemožňuje proudové generování dokumentu.

Blok tedy začíná posloupností hodnot typu UBNumber, nazývaných atributy bloku a následovat bude datová část bloku, která bude případně interpretována jako posloupnost podbloků. Na začátku je tedy hodnota:

UBNatural - AttribPartLength

Což je délka posloupnosti hodnot v kódování UBNumber

To, že daná hodnota je typu UBNatural znamená, že v proudu dat je dopředu znám nejen počet, ale i prostor zabíraný atributy. To může působit problémy pro velké posloupnosti atributů. Cílem však je, aby počet atributů byl co nejmenší a všechny podstatné hodnoty byly realizovány jako samostatné bloky. Také je potřeba nějakým způsobem určit, jaký je typ bloku.

Struktura dokumentu kódovaného pomocí protokolu XBUP má následující strukturu:

Hodnota AttribPartLength = 0 znamená, že dále nenásledují žádné další hodnoty UBNumber a tento blok je terminální. V kombinaci s uzlovým blokem umožňuje omezit nekonečnou posloupnost podbloků.

Kdy datovou část bloku interpretovat jako další bloky a kdy jako prostá data je možné volit několika způsoby:

• Blok má jediný atribut
  Pokud má blok jediný atribut a tím je délka datové části, nemá tento blok jak reprezentovat svůj typ, pouze pomocí rodičovských bloků.
   
• Všechny atributy bloku jsou nulové
  Jinou možností je umožnit bloku uvádění volných atributů, které v podstatě umožňuje alokovat případné volné místo.
   
• První atributy bloku jsou nulové
  Další možností je vyhradit pro rozpoznání datového bloku počáteční atributy a zbývající využít pro další údaje o datovém bloku.
   
• Zda je blok datový určuje interpretace typu bloku
  Toto řešení znemožňuje obecné zpracování a zobrazení dokumentu.
   

Datový blok nemusí obsahovat žádné další atributy, které mohou být uvedeny v nadřazených blocích a zatím se tato varianta jeví jako dostačující. V atributové části je pak pouze jediný atribut:

UBENatural - DataPartLength

Tento atribut určuje délku posloupnosti shluků bitů, která následuje. Tato posloupnost je interpretována jako bitová posloupnost bez dalšího významu. I zde je podporována hodnota nekonečno pro signalizaci neomezené velikosti tohoto bloku, která umožňuje generovat proud dat bez znalosti množství dat. S tím vyvstává problém ukončení tohoto typu bloku:

• Neukončovat - Jednou ze zřejmě nevhodných možností je při výskytu nekonečného bloku jeho ukončení nijak nerozpoznávat. Tím by však blok ztratil smysl v hierarchii a stal by se rozšířenou oblastí.
• Atribut - Další možností je vyjádření binárních dat jako hodnoty atributu, a následující bity považovat za nulové. Pro tyto účely je však možná použít přímo blok s jedním atributem.
• Ukončený nulou - Stejně jako u bloků bude i v tomto případě vhodné zvolit nějaký terminální symbol - nejlépe bitový shluk 0

Ukončení nulovým shlukem sebou přináší problém, jak v bitové posloupnosti vyjádřit posloupnost nul:

• Vyloučení - Jednou z možností je tento problém ignorovat a podobně jako například u zero-terminated řetězců používat pouze nenulové hodnoty. Toto řešení je však neuspokojivé, především v případě menší velikosti clusteru.
• Přímý přepočet - Je možné provádět přímý přepočet hodnot o základu 255 na hodnoty o základu 256, což ale vyžaduje přečtení všech hodnot před určením výsledné bitové posloupnosti.
• Přepočet hlavičky - Předchozí variantu je možné omezit pouze na jediný bit a přepočet základu provádět pouze u vybraného bitu.
• Posun - Jako přijatelná varianta se jeví řešení posunu po celých bitech. Pokud je hodnota shluku 0, jde o ukončovací sekvenci, pro hodnotu 1 se pak vezme pouze 7 platných bitů a ve všech ostatních případech se převezmou všechny bity. To má za následek, že nulové sekvence a sekvence s bity 1 po intervalu délky clusteru jsou kódovány velice neefektivně. Jde však o relativně přijatelný kompromis ke složitosti převodu.

Pokud je uveden více než jeden atribut, je blok považován za uzlový blok nebo listový blok. První hodnota je v obou případech:

UBENatural - SubPartLength

Nenulová hodnota určuje délku posloupnosti shluků bitů, která následuje. Ta je pak interpretována jako posloupnost bloků.

Speciálním případem uzlového bloku je blok s DataPartLength = 0, což znamená, že daný blok nemá žádné podbloky. Tento blok nese informaci pouze v podobě atributů.

Podobně jako u kódování čísel, i zde bych rád uvedl argumenty podporující zvolený způsob realizace stromové struktury.

• Neuvedení délky bloku - Tento princip, zavedený pomocí konstanty pro nekonečno, je nutný, protože ne vždy jsou dopředu známy velikosti podbloků a v některých případech může být předpokládáno, že posloupnost podbloku by neměla nikdy končit.
   
• Posloupnost hodnot - Zřejmě každý blok musí začínat alespoň jednou hodnotou typu UBNumber, která musí uvádět délku tohoto bloku.
   
• Pořadí částí - Atributová část bloku by měla předcházet datové části, neboť atributy mohou mít, mimo jiné, kritický význam pro to, jestli se bude datová část bloku vůbec zpracovávat.
   
• Pořadí atributů - Zřejmě délka atributové části musí předcházet délce datové části. V opačném případě by to neodpovídalo uvedení pořadí částí bloku. Navíc délka datové části by měla být zahrnuta mezi ostatní atributy, protože se v podstatě jedná o atribut bloku.
   
• Délka atributové části - Umožnění nekonečné posloupnosti atributů v atributové části nemá smysl, protože takové atributy by měly být realizovány jako bloky.
   
• Dokument jako jeden blok - Dokument je reprezentován jediným kořenovým blokem a data, která se nachází za tímto blokem jsou interpretována jako datový blok. To umožňuje realizaci nekonečného datového bloku bez zarážky a využití protokolu XBUP jako hlavičky takového proudu (např. pro MPEG, MP3).

Protokol tvoří jazyk nad abecedou {0,1}, který je obecně typu 0. Nicméně je možné uvést pro orientaci výskyt jednotlivých struktur jako gramatiku protokolu, bez nutnosti zavádět přímý vztah k jejich binárnímu vyjádření.

Pro vyjádření a pochopení základní blokové struktury protokolu by mohla posloužit následující gramatika. Slova psané malými písmeny jsou terminály.

Document ::= filehead + Block
Block ::= Attributes + Blocks | datablock
Attributes ::= Attributes + attribute | epsilon
Blocks ::= Blocks + Block | epsilon

Tato bezkontextová gramatika vyjadřuje to, že celý dokument tvoří jediný blok, každý blok je buď datový blok, nebo má dvě oddělené části, libovolný počet atributů a podbloků. Atributy jsou v bloku uváděny jako první a bloky jsou definovány rekurzivně. Tuto gramatiku je možné rozšířit tak, aby vyjadřovala další vlastnosti.

Tato gramatika popisuje navíc možnost použití terminátoru.

Document ::= filehead + Block
Block ::= Stdblock | Stdtermblock | Datablock | Datatermblock
Stdblock ::= Attributes + Blocks
Stdtermblock ::= Attributes + Blocks + terminator
Datablock ::= datablob
Datatermblock ::= datablob + terminator
Blocks ::= Block + Blocks | epsilon
Attributes ::= attribute + Attributes | epsilon

Obzvláště při parsování se bloky vyskytují v daném omezeném pořadí, které je možné taktéž omezit gramatikou, která je bezkontextová.

Document ::= Block
Block ::= blockBegin + Attributes + Blocks + blockEnd | blockBegin + blockData + blockEnd
Blocks ::= Block + Blocks | epsilon
Attributes ::= blockAttribute + Attributes | epsilon

Následující graf vyjadřuje základní graf výskytu událostí při postupném parsování dokumentu.

Vysvětlivky:
a - atribut bloku (blockAttribute)
b - začátek bloku (blockBegin)
d - datová část bloku (blockData)
e - konec bloku (blockEnd)

V případě velkých datových bloků může být jejich zpracování v paměti problematické. Z tohoto důvodu je možné a většinou i vhodné použít jemnější dělení na jednotlivé bajty. Mezi oběma typy gramatik je možné převádět události na odpovídající význam.

Vysvětlivky:
a - atribut bloku (blockAttribute)
b - začátek bloku (blockBegin)
d - jeden bajt datové části bloku (blockData)
e - konec bloku (blockEnd)

Naopak je také možné některé události sloučit, například atributy a data dát jako součást události začátku bloku.

Vysvětlivky:
b - začátek bloku s atributy (blockBegin)
d - datový blok s daty (blockData)
e - konec bloku (blockEnd)

Proud je správně utvořen (well-formed) pokud platí následující podmínky. Jsou uvedeny pojmenování chybových stavů v případě, že uvedená podmínka není splněna.

• V každém bloku konec posledního atributu odpovídá konci atributové části bloku (Attribute Overflow)
• V každém bloku konec posledního podbloku odpovídá konci datové části bloku (Block Overflow)
• Konec souboru se nachází až za koncem kořenového bloku (Unexpected End)
• Terminální blok je přítomen pouze u bloků kam náleží (Unexpected Terminator)

Během vytváření návrhu struktury se ukázalo, že bude vhodné zavést více úrovní realizace dat. Důvodem je možnost zpracovávat dokument na různých úrovních jeho složitosti a především provádět kontrolu platnosti na různé podmínky, podle dostupnosti specifikací.

Kódování a základní bloková struktura je označována jako úroveň 0. Není to totiž plnohodnotná varianta protokolu, protože pouze specifikuje způsob stromové organizace dat bez způsobů realizace přenosu informací. Zobrazuje jednotlivé bloky bez interpretace jejich obsahu, pouze jako bloky 4 základních typů. Je možné validovat dodržení blokové struktury (syntaktická kontrola).

Další úrovně rozšiřují interpretaci bloků o jejich typ. Dále stanovují způsob specifikace typu a základní bloky. Další rozšíření by mělo umožnit určit povolené rozsahy hodnot atributů, povolené podbloky a případně i jejich pořadí, způsob transformace a definici významu. Na vyšších úrovních bude možné validovat dokument podle úrovně požadovaných rozšíření.