XBUP - Dokumentace: Navrhované vlastnosti

Na vyšších úrovních by měly být deklarovány další rozšíření, které by měly poskytnout protokolu nové užitečné vlastnosti. Dosud nebylo rozhodnuto, na jakou konkrétní úroveň či zda vůbec by měly být do projektu zařazeny.

Následující vlastnosti se zabývají vnitřní strukturou protokolu. Většina z nich je uvedena v návrhu úrovní.

V případě rovnocenných bloků je lze uvádět v libovolném pořadí. Je vhodné umožnit vkládání dalších nepovinných bloků jak před, tak za esenciální bloky. Přesto prokládání těchto bloků asi není příliš vhodné. Možnosti pořadí uvádění bloků bude potřeba ještě promyslet.

Cílem je dosáhnout snížení velikost výsledného formátu pomocí některých z následujících technik:

• sloučení dvou bloků do jednoho (sourozenci, rodič - potomek)
• implicitní hodnota atributu - možnost jejího vynechání
• automatická přítomnost bloku - vynechání / napojení

Tyto operace by samozřejmě neměly způsobit omezení jiných vlastností, jako například rozšiřitelnosti. Bude potřeba ještě promyslet.

Tato vlastnost by měla umožňovat rozpoznání typu/významu/vlastnosti bloku i bez případné kompletní znalosti specifikace. Například v případě transformačních bloků by se mohlo hodit rozpoznat to, že obsah bloku lze získat až po aplikace transformace. Tyto vlastnosti by mohly mít také souvislost s dědičností a rozšiřováním významu bloků.

Tyto vlastnosti se netýkají přimo specifikace protokolu na nějaké úrovni, ale spíše způsobem práce s dokumentem z vnějšku.

Spojováním je zde myšleno souběžné zpracovávání více souborů se stejnou strukturou obsahu, které mají nějaký typ souvislosti. Nastává v situaci, kdy dvojice souborů sdílí stejnou stromovou strukturu a jednotlivé bloky nesou informaci, která je ekvivalentní jednomu souboru se sloučenými bloky.

Příkladem mohou být multimediální kontajnery. Jedním z řešení je umístit audio a video data, případně další datové proudy, jako například titulky, do samostatných souborů a ty pak přehrávač všechny při přehrávání volitelně zpracovává. To umožňuje přiložit titulky k video souborům bez nutnosti změny jejich obsahu a tedy případného porušení kontrolních součtů a dalších propriet. Druhým extrémem je spojení všech těchto proudů do jediného prokládaného souboru. Oba extrémy i jejich kombinace, mají smysl. Podobně je vhodné očekávat případy, kdy je například datový proud videa rozdělen na obraz a zvuk a posílán více proudy souběžně, případně vzniká spojováním více nesourodých videoproudů za sebou.

Příklad, který je bližší a aktuálnější pro protokol XBUP, je katalog. Základní katalog, v současné variantě, obsahuje pouze rozsahy povolených skupin, bloků a počty atributů. Chceme-li například tuto informaci rozšířit o textový popis jednotlivých bloků a atributů, je možné použít buď externí soubor, nebo informace začlenit přímo do katalogu. V tomto případě se zdá být první varianta vhodnější, neboť umožňuje volitelně měnit použitý jazyk a nevynucuje stahování jazyka, pokud o něj není explicitně žádáno.

Hlavní úvaha, kterou se zde zabývám, je rozdělení definice dokumentu na základní (úroveň 1) a další samostatné soubory, které mohou například do stejné stromové struktury zavádět textové popisy v různých jazycích, nebo ikony, či typy atributů a dědičnost. Tyto samostatné soubory budou obsahovat stejnou stromovou strukturu a problém se nachází především ve zpracování více takových dokumentů, případně problémům s jejich nekonzistencemi atp.

V případě porovnávání dvou dokumentů můžeme narážet na problémy s pořadím bloků a s použitím různých kompresí a transformací. Z tohoto důvodu by bylo vhodné navrhnout výchozí tvar dokumentu (podobně jako je tomu u XML). Druhou věcí je konstrukce formátu pro uchování rozdílů dvou dokumentů s možností jejich aplikace.

V pozdější fázi by také bylo vhodné definovat přesněji isomorfismy a ekvivalentní vyjádření bloků, stejně jako míru podobnosti na různě esenciálních blocích.

Podobně jako v případě XML i zde bude nutné vytvořit tzv. normální tvar, tj. tvar ve kterém je možné dokumenty porovnat na shodnost. Základem nemůže být nekomprimovaný tvar, protože komprese také vyjadřuje určitou vlastnost. Pravděpodobně i zde bude zaveden systém úrovní.

Obecně lze datové soubory vždy porovnávat vzhledem k jejich binárnímu tvaru. Avšak podobně, jak to je tomu v případě textových souborů, jejichž porovnání zohledňuje řádkovou strukturu, bude i pro formát XBUP vhodné navrhnout algoritmy pro porovnání dvou dokumentů, zohledňující blokovou strukturu dokumentu. Případně také program pro vytvoření rozdílového souboru, po jehož aplikaci bude získána nová verze. Datové bloky budou porovnávány klasickými metodami pro binární formáty.

Bude vhodné sestavit základní gramatiku. Zřejmě je možné gramatiky odlišit podle různé úrovně detailu a podle zavedených úrovní protokolu. Nejdetailnější je úplný systém kontrolující správnost bitové posloupnosti. Ten ověřuje i základní validitu na dané úrovni.

Jednou z možností je přechodový systém parseru. Ten vyjadřuje, v jaké možné posloupnosti lze tahat, či posílat položky odpovídající struktuře formátu.

Cílem této gramatiky je umožnit validaci platnosti dokumentu, a to pro každou úroveň. (nebo alespoň ty nižší)

Příklad: adresace více bloků

Datové typy konstantních délek
Nabízí se možnost specifikovat již na úrovni protokolu konstatní datové typy, jako například Boolean, Int32, Int64, které by byly realizovány nad datovým blokem.

Navíc je vhodné zohledňovat faktory, které se například používají u relačních databází - normální formy a nejspíš i vlastnosti tříd v objektovém programování, jako jsou dědičnost, kompozice.

Z charakteru protokolu je více než vhodné, aby byly v podstatě jakékoliv prvky indexovány. To rozhodně zhoršuje čitelnost a nutí programátory se učit kromě názvů i posloupnosti čísel, které těmto názvům odpovídají. Tyto indexy bude vhodné co nejlépe odstínit na aplikační úrovni.

Seznam:
Základní blok pro konstrukci seznamu obecně libovolných položek.

• Návrh 1: Říká se pouze, jaký má seznam počet prvků. Prvky stejné pořadí v jakém jsou uvedeny. Jednotlivé položky mohou být jakéhokoliv typu.
  Z tohoto by pak bylo možné vytvořit také:
  • množinu: prvky musí být různé, ignoruje se pořadí
  • multimnožinu: ignoruje se pořadí
  • pole: prvky musí být stejného typu

  Prvky s vyšším indexem než počet položek by pak byly další vlastnosti tohoto seznamu. Problém s nekonečnými seznamy. Problém s řídkými seznamy.

• Návrh 2: Říká se pouze, že se jedná o seznam. Počet položek se určí z počtu podbloků
• Návrh 3: Říká se jaký je počet položek a následují odkazy na jednotlivé položky

Katalog může být organizován v jediném stromu, nebo může být pro každý typ vytvořen vlastní strom.

Skripty pro manipulaci a konverzi. Především by mělo být možné tento jazyk použít jako obdobu XSLT pro transformaci dokumentu do jiného tvaru.

Možná další úroveň: Plná podpora jazyka ProgJazy a jeho obslužných modulů. Umožnění autokonfigurace a automatické implementace kompatiblity.
Autokonfigurace - zavedení modulů zpracovávajících jednotlivé skupiny bloků a jejich komunikaci s aplikačním programem a předání výsledku po definovaném rozhraní v požadovaném tvaru

Pravděpodobně nejvyšší úroveň: Navázání logické komunikace mezi dvěmi neznámými komunikačními entitami. Zašle se úplný komunikační popis, začátek pravděpodobně zavedení logických funkcí a matematických formulí, později definice jazyka, nakonec komunikační rozhraní pro obraz a zvuk.

Úvahy nad programovací interpretací:

Podobně jako u jiných formátů, lze i zde data interpretovat jako programový předpis. Například u obrázku: Dekompresuj a vysázej. Z toho lze uvažovat:

Cílem samozřejmě je dosáhnout toho, aby byla data co nejabstraktnější. Například obrázek je mapa buď kolmo vyzařovaného světla v určených normalizovaných frekvencích elektromagnetického záření, nebo také vlastnost odrazivosti plochy. Obé má svůj smysl (RGB, CMYK). Klasická bitmapa je tak vlastně už jistá forma komprese, která říká, že tato spojitá rovinná mapa se rozděluje na diskrétní, či různě spojité oblasti (čtverce, obdelníky, trojúhelníky, šestiúhelníky, prolnuté kruhy), které mají udanou právě jednu barvu (vzorkování). Následuje pak obvykle další komprese (např. LZW, JPEG) atd.

• Hranice využitelnosti atributů
  U atributů lze zvažovat, zda by nebylo vhodnější je uvést jako samostatný blok. Například velikost obrázku, aby mohl být použit odkaz by, měla být uvedena jako samostatný blok?
  Návrh 1: Použít atributy pouze jako řídící odkazy
  Každá vlastní hodnota by měla svůj blok a atributy bloku by na ni pouze ukazovaly, nebo ani to ne, pokud by u typu bloku bylo rozlišováno o jaký atribut se jedná.
• Realizace vícesložkových atributů
  Pokud bychom jako atribut požadovali reálné číslo, je nutné jej realizovat jako posloupnost dvou po sobě jdoucích celých čísel (viz. UBReal), nebo jako dvě čísla X-Base, X-Mantis? Nebo uvažovat reálné čísla jako samostatný blok?
• Komunikační protokol
  Bude vhodné navrhnout komunikační protokol ala RPC pro přístup k dokumentům ve formátu XBUP ve stylu - pošli daný blok, parsuj na straně serveru, proveď operaci nad blokem...