Pro účely formátování dokumentu a to jak z hlediska vstupu, tedy vyplňování formuláře, tak i z hlediska výstupu, tedy tiskových šablon a přehledů, je možné v XDS definovat tzv. pohledové dokumenty. Z hlediska uživatele pracujícího s dokumenty jde o naprosto samostatný a plnohodnotný typ dokumentu, který má nejen svůj formulář a tiskové šablony, ale také je možné vytvářet přehledy založené na těchto pohledových typech. Z hlediska databáze pohledový dokument vlastně neexistuje, přesněji řečeno nevytváří se pro něj samostatné DAD a tedy ani odpovídající objekty v databázi (tabulky, sloupce, pohledy, procedury...).

Pohledový dokument je vždy svázán s jiným, nepohledovým - řekněme databázovým - dokumentem. A to vždy právě s jedním. Pohledový dokument se nemůže nikdy stát zdrojovým dokumentem, protože nemá své vlastní úložiště. Naopak je schopen přebírat zdrojová propojení svého databázového protějšku, na nějž je provázán. Zjednodušeně řečeno jde o to, že jeden typ dokumentu (ten databázový) může prostřednictvím jiných dokumentů (těch pohledových) nabízet různé podoby stejných dat. Nejlépe to opět objasníme na příkladu.

Uvažujme dokument klient a dokument smlouva, které jsou oba databázovými dokumenty. Řekněme, že klient může uzavřít mnoho druhů smluv, ale každá je z hlediska týmu který s dokumenty pracuje brána jako obchod s určitým obratem, kde je třeba znát, kdo je klientem, kdo daný obchod uzavřel z hlediska týmu, kdy se tak stalo, od kdy smlouva platí atd. Řekněme, že tým pracuje jako zprostředkovatel mezi klientem a třetí stranou, která bude danou smlouvu zajiš"ovat. Každý tento poskytovatel však požaduje, aby měla smlouva určité údaje, které jsou nazývány přesně danými názvy, i když jednotlivé hodnoty znamenají v podstatě totéž (mohou například existovat různé papírové formuláře daných poskytovatelů, které je třeba nejen vyplnit, ale také evidovat). Je zřejmé, že si nevystačíme s jediným elektronickým formulářem dokumentu smlouva, ale na druhou stranu by z hlediska potřeb evidence daného týmu bylo zapotřebí mít jednotnou evidenci.

Nabízí se dva způsoby jak to vyřešit a jejich výběr závisí na různých okolnostech. První možností je použít pouze databázové dokumenty s různými názvy kolonek a příp. i různou strukturou a každému z nich dát rozhraní smlouva. Vznikly by tak v databázi samostatné tabulky pro jednotlivé typy a pomocí rozhraní by se dali spojit do jednoho uživatelského seznamu. Pokud by však typů bylo mnoho a nebo se často obměňovali (práce z rozhraním se zpomaluje s počtem typů, na které je aplikováno) bylo by lepší,vzhledem ke klíčovému významu smluv a tedy i častým požadavkům na práci s nimi, použít jediného univerzálního dokumentu smlouva, který by v sobě zahrnoval všechny údaje potřebné pro jednotlivé typy smluv a pro každý typ by byl vytvořen speciální pohled, který by vybral potřebné oblasti a prvky ze smlouvy pro daný typ a dal by jim potřebné názvy. Výhod takového řešení je hned několik.

Jednak je to již zmíněná rychlost práce, kterou skýtá zahrnutí do jediného databázového dokumentu naproti odděleným datovým evidencím. Rozhraní opravdu slouží spíše pro dohledávání údajů a sestavování ne příliš často používaných seznamů. Jednak je to také fakt, že pohled nevytváří žádné další struktury v databázi. To nám umožňuje snadno se zbavit určitého typu dokumentu a nahradit ho jiným, aniž bychom se museli zbavit dat, které obsahovala původní forma. V neposlední řadě je to také fakt, že v přehledech založených na rozhraní se nedají tvořit agregační funkce (tedy zatím ne - dokud agregaci nebude podporovat XSLT formátování používané v systému flexideo pro tvorbu přehledů).

Navíc každý databázový dokument si sebou nese informaci, jakým pohledem byl vytvořen (pokud byl vytvořen pohledem) a je tedy možné, vytvářet přehledy jen pro jednotlivé pohledy. Pokud tedy budeme mít jeden databázový dokument "Smlouva" a například pět různých pohledů nazvaných "Formulář A" až "formulář F", můžeme si vedle přehledu všech smluv v evidenci vytvořit i přehledy jednotlivých formulářů A až F pro různé poskytovatele.