Podcast on Introduction to XML: Syntax and Validation

Kapitoly

Co je to vlastně XML?

Cesta k XML: Krátká historie

K čemu se XML používá v praxi?

Základy syntaxe: Elementy a značky

Jak správně pojmenovat značky?

Atributy: Doplňující informace

Komentáře, entity a CDATA

Managing App Text

What Makes XML 'Correct'?

Avoiding Name Conflicts

Placing Your DTD

Declaring Elements

Counting Your Elements

All About Attributes

Final Rules and Recap

Přepis

James: ...počkat, takže celá ta věc je vlastně jenom přísnější verze něčeho mnohem staršího? To je neuvěřitelné.

Olivia: Přesně tak! Zní to jako krok zpět, ale ve skutečnosti to byla revoluce. Zjednodušení bylo klíčem.

James: Dobře, o tomhle jsem neměl tušení – a myslím, že to musí slyšet každý. Posloucháte Studyfi Podcast a dnes se noříme do světa XML.

Olivia: Připravte se, bude to jízda!

James: Takže, Olivie, začněme od úplného začátku. Když se řekne XML, spousta lidí si představí nějaký složitý kód. Můžeš to pro nás demystifikovat?

Olivia: Jasně. Zkratka XML znamená eXtensible Markup Language, tedy Rozšiřitelný značkovací jazyk. Klíčové slovo je tady "rozšiřitelný".

James: Rozšiřitelný? Jakože si ho můžu přizpůsobit?

Olivia: Přesně! Představ si to jako stavebnici LEGO bez návodu. XML ti nedává hotové kostky jako třeba HTML, které má předdefinované značky jako <p> pro odstavec nebo <h1> pro nadpis.

James: Aha, takže v HTML mám jasně dané dílky, co dělají co.

Olivia: Přesně tak. Ale XML je spíš jako továrna na LEGO. Dává ti pravidla, jak si můžeš vytvořit své vlastní, úplně nové kostky – neboli značky – pro cokoliv potřebuješ. Proto se mu říká "metajazyk". Je to jazyk pro vytváření dalších jazyků.

James: Takže si můžu vytvořit značku <pizza> s vnitřními značkami <sýr> a <šunka>? To zní skvěle!

Olivia: Můžeš! A to je ta hlavní síla. XML se nezajímá o to, jak data vypadají, ale o to, co ta data znamenají. Jeho úkolem je data strukturovat a přenášet, ne je zobrazovat.

James: Zmínila jsi, že XML je zjednodušenou verzí něčeho staršího. Můžeme se na tu historii podívat?

Olivia: Určitě. Ta cesta začala už v roce 1967 s něčím, co se jmenovalo GenCode. Cílem bylo mít jeden univerzální jazyk pro dokumenty.

James: Šedesátá léta? To je mnohem dřív, než jsem si myslel.

Olivia: Přesně. Z toho se pak vyvinul SGML, neboli Standard Generalized Markup Language, v roce 1986. A SGML byl... ...kolos. Byl neuvěřitelně mocný, ale taky strašně složitý.

James: Jako ten strýček, který umí všechno, ale nikdo mu nerozumí?

Olivia: Perfektní přirovnání! SGML byl jazyk na definování jiných značkovacích jazyků. Byl to ten největší boss. Ale pro použití na rodícím se internetu byl prostě příliš komplikovaný a pomalý.

James: A tady přichází na scénu XML, náš hrdina.

Olivia: Přesně. W3C, tedy World Wide Web Consortium, vzalo SGML, odstranilo z něj všechny složitosti a vytvořilo XML jako jeho zjednodušenou, ale mnohem přísnější podmnožinu.

James: Přísnější? Jak to?

Olivia: Méně flexibility znamená rychlejší zpracování. XML má striktní pravidla, která musíš dodržovat. A právě díky tomu je tak robustní a snadno se s ním strojově pracuje. Žádné dohady, žádné výjimky.

James: Dobře, takže je to nástroj pro strukturování dat. Kde se s ním dneska běžně setkáme? Protože ho většinou nevidíme přímo na webových stránkách.

Olivia: Nevidíš, ale je skoro všude pod kapotou. Používá se pro konfigurační soubory – třeba uživatelské rozhraní v Android aplikacích je definované v XML. Vývojová prostředí jako NetBeans nebo PHPStorm ho používají pro svá nastavení.

James: Aha, takže věci, které běží na pozadí.

Olivia: Přesně. A pak je tu obrovská oblast výměny dat. Když třeba e-shop posílá data o svých produktech cenovým srovnávačům jako Heureka.cz, často to dělá pomocí XML souboru. Každý produkt má své značky: <product>, <price>, <manufacturer>.

James: Takže je to vlastně univerzální jazyk, kterým si můžou povídat různé počítačové systémy?

Olivia: Perfektně řečeno. Je to jako digitální esperanto pro data. Dokonce i formáty jako .docx z Microsoft Office nebo .svg pro vektorovou grafiku jsou v jádru postavené na XML.

James: Pojďme se podívat na tu syntaxi. Říkala jsi, že je přísná. Co jsou ty základní stavební kameny?

Olivia: Úplným základem je "element". Element se skládá z otevírací značky, nějakého obsahu a uzavírací značky. Například <jméno>Jan</jméno>.

James: Jednoduché. Jaké jsou ty přísné pravidla?

Olivia: Pravidlo číslo jedna: Každá otevírací značka musí mít svou uzavírací značku. Žádné výjimky. Uzavírací značka má na začátku lomítko, jako v </jméno>.

James: Jasně. Co dál?

Olivia: Pravidlo číslo dvě: Správné vnořování. Značky se nesmí křížit. Představ si to jako ruské panenky Matrjošky. Musíš zavřít tu vnitřní, než zavřeš tu vnější.

James: Takže <b><i>Takhle je to správně</i></b> a ne <b><i>Takhle špatně</b></i>. To mi připomíná zamotaná sluchátka. Vždycky musíš rozmotat ten vnitřní uzel jako první.

Olivia: Přesně tak! A pravidlo číslo tři: XML je case-sensitive, tedy rozlišuje velká a malá písmena. Značka <kniha> je úplně něco jiného než značka <Kniha>.

James: Když si můžu tvořit vlastní značky, existují nějaká doporučení, jak na to?

Olivia: Rozhodně. Jména značek můžou obsahovat písmena, čísla a pár dalších znaků, ale musí začínat písmenem. Důležité je, že název nesmí začínat písmeny "xml" v žádné kombinaci velikosti písmen.

James: Takže <xmlData> je zakázáno, ale <dataXML> je v pohodě?

Olivia: Přesně. A co se týče doporučení – jména by měla být popisná, ale zároveň stručná. Třeba <datum_narození> je lepší než jen <datum>, protože je to jasnější. Ale <jméno_mého_starého_přítele_z_dětství> je už asi trochu moc.

James: Chápu, najít tu zlatou střední cestu. A co speciální znaky jako pomlčky nebo tečky?

Olivia: Tady opatrně. Některé programy můžou brát pomlčku jako operátor mínus, takže <book-name> může dělat problémy. Tečka v <book.name> taky může být interpretována speciálně. Nejbezpečnější je používat podtržítka nebo takzvanou velbloudí notaci, třeba bookName.

James: Dobře, to byly elementy. Ale v příkladech jsem často viděl i něco uvnitř té otevírací značky. Co to je?

Olivia: Tomu se říká "atribut". Je to způsob, jak k elementu přidat doplňující informace nebo metadata. Například <soubor typ="obrázek">foto.jpg</soubor>. Tady je typ název atributu a "obrázek" je jeho hodnota.

James: Aha, takže to upřesňuje, o jaký soubor se jedná.

Olivia: Přesně. A kriticky důležité pravidlo: hodnoty atributů musí být VŽDY v uvozovkách. Buď v dvojitých ("") nebo jednoduchých ('').

James: Kdy bych měl použít atribut a kdy raději vnořený element? Je lepší <osoba věk="30"> nebo <osoba><věk>30</věk></osoba>?

Olivia: Skvělá otázka, která trápí hodně vývojářů! Obecně platí, že atributy jsou dobré pro jednoduchá, jednoznačná metadata. Třeba ID prvku nebo typ. Pokud ale ta informace může být složitější, mít v budoucnu další části, nebo pokud jich může být víc, je skoro vždycky lepší použít vnořený element.

James: Protože atribut nemůže mít vlastní strukturu, že? Je to jen jeden kus textu.

Olivia: Přesně tak. Elementy jsou rozšiřitelné, atributy ne. Elementy vyhrávají, když jde o flexibilitu a čitelnost pro složitější data.

James: Ještě poslední věci k syntaxi. Co když si chci do kódu napsat poznámku, kterou má procesor ignorovat?

Olivia: Na to slouží komentáře. V XML vypadají takhle: <!-- Toto je komentář -->. Můžou být kdekoliv v dokumentu, kromě úplného začátku před XML deklarací nebo uvnitř jiné značky.

James: To je užitečné. A co když potřebuju v textu použít znak, který je součástí syntaxe XML, třeba znak <?

Olivia: Na to máme "entity". Jsou to speciální kódy, které zastupují rezervované znaky. Pro menšítko (<) použiješ &lt;, pro většítko (>) &gt; a pro ampersand (&) &amp;.

James: Takže když chci napsat text "5 < 10", musím v XML napsat 5 &lt; 10?

Olivia: Přesně tak. Jinak by si parser myslel, že začínáš novou značku a zkolaboval by.

James: To dává smysl. Poslední věc: slyšel jsem o něčem, co se jmenuje CDATA. K čemu to je?

Olivia: CDATA je taková úniková zóna! Znamená to "Character Data" a je to sekce, kterou XML parser úplně ignoruje a bere její obsah jako čistý text. Vypadá to takhle: <!]>.

James: A k čemu je to dobré?

Olivia: Je to skvělé, když potřebuješ do XML vložit třeba kus HTML kódu nebo JavaScriptu, který je plný znaků < a &. Místo toho, abys každý znak nahrazoval entitou, prostě to celé zabalíš do CDATA a máš klid.

James: Takže je to vlastně takový štít proti XML pravidlům pro určitou část dokumentu.

Olivia: Přesně tak. Je to velmi mocný nástroj. A tím jsme vlastně probrali všechny klíčové základy syntaxe XML! Od historie přes strukturu až po tyhle speciální případy.

James: Fantastické. Myslím, že teď už se nikdo nemusí bát, když uvidí soubor s koncovkou .xml. Po krátké pauze se podíváme na to, jak můžeme ověřit, jestli je naše XML struktura správná, pomocí něčeho, čemu se říká DTD a XML Schéma.

James: So that makes sense for the visual layout. But what about all the actual text in an app? The buttons, the descriptions... you're not just hard-coding that stuff, right?

Olivia: Definitely not! That would be a nightmare to manage, especially for different languages. In Android, we handle this with a special file, usually called strings.xml.

James: XML... okay, that looks a bit old-school, not gonna lie.

Olivia: It’s a classic for a reason! Think of it as a dictionary for your app. Each piece of text gets a unique name, like a key, and then the actual text is the value. It's super organized.

James: So you're separating the content from the code. That's smart.

Olivia: Exactly. It makes updating text or adding a new language so much easier. You just edit this one file.

James: Looking at this structure, with all the brackets and nesting... it seems like it would be easy to mess up.

Olivia: It can be, and that's why there are two key ideas for a 'correct' XML document: being well-formed and being valid.

James: Okay, what's the difference there? Aren't they the same thing?

Olivia: Great question. They're related but distinct. Think of 'well-formed' as having correct grammar. You've closed all your tags, you have one main root element... the basic syntax is right.

James: So the computer can read it without crashing. Got it.

Olivia: Precisely. Now, 'valid' is a step further. A valid document is not only well-formed, but it also follows a specific set of rules, like a blueprint or a recipe, defined in another file.

James: So, well-formed is 'you spoke English correctly,' and valid is 'you correctly followed the recipe I gave you.'

Olivia: That's the perfect analogy! You nailed it. Your app needs both to work properly.

James: Okay, so you have these files... but what happens if you're pulling in different XML files and they both use the same name for an element? Like, two files both have a <name> tag.

Olivia: Ah, you've just discovered why we need something called XML namespaces. It’s a way to avoid name collisions.

James: Namespaces... sounds familiar from other coding stuff.

Olivia: It's the exact same concept. The best way to think of it is like a database query. Imagine you have an employee table and a section table, and both have a column called 'name'.

James: Right, you'd have to specify employee.name or section.name to tell them apart.

Olivia: Exactly! A namespace in XML does the same thing. It adds a short prefix, like h:table or info:name, to make sure every element's name is unique, even when you're mashing different documents together.

James: That's clever. So you're basically giving each tag a last name to avoid confusion.

Olivia: A last name! I love that. And it's essential for more complex tools like XML Schema. But how does the app actually parse these files and use those schemas? Let's dive into that next.

James: And that brings us to our final topic for today... which feels like the glue holding all this XML stuff together: DTDs.

Olivia: That's a perfect way to put it, James! DTD stands for Document Type Definition. It's basically the rulebook or the blueprint for your XML document.

James: A rulebook! I like that. It tells the XML what it's allowed to look like?

Olivia: Exactly. It defines the legal building blocks. It says which elements can be there, in what order, and what attributes they can have. It ensures consistency, which is super important.

James: So, where does this rulebook live? Do you just stick it at the top of the file?

Olivia: You can! That's called an internal DTD. It's declared right at the beginning of the XML file, right after the <?xml ... ?> declaration.

James: Okay, so it's all in one place. What are the other options?

Olivia: You can also have an external DTD. This is where the rules live in a completely separate file. You just link to it from your XML document.

James: Ah, that seems useful if you're using the same rules for lots of different XML files.

Olivia: You got it. It's all about reusability. And there's even a third option: a combination. You can link to an external DTD and then add or override some specific rules internally.

James: Flexible! So how do you link to that external file?

Olivia: You use the <!DOCTYPE> declaration again, but you add the keyword SYSTEM for your own files, or PUBLIC for a common, public standard... like for SVG or RSS files.

James: Okay, so once we've placed our DTD, how do we write the actual rules? Let's start with elements.

Olivia: Great question. The syntax is <!ELEMENT ...>. You give the element name, and then you define what's allowed inside it. We call that the content.

James: And what can the content be?

Olivia: It can be simple text, which we define with the keyword #PCDATA. That stands for Parsed Character Data.

James: Just regular text, basically.

Olivia: Yep. Or, the content can be other elements! For example, you could say a person element must contain a firstname element and then a surname element, in that order.

James: So you're creating a required structure, a hierarchy.

Olivia: Precisely. You can also allow a choice. If you use a pipe symbol |, it means "or". So you could have an element that contains either a diameter or a radius, but not both.

James: I've seen some weird symbols next to elements in DTD examples... like a question mark or a plus sign. What's that about?

Olivia: Ah, the qualifiers! They're super important. They control how many times an element can appear.

James: Let me guess... they're like quantifiers in regular expressions?

Olivia: Exactly! A question mark ? means zero or one time. The element is optional. An asterisk * means zero or more times. And a plus sign + means one or more times.

James: And if there's no symbol?

Olivia: Then it has to appear exactly once. Let me give you an example. Imagine a DTD for a university.

James: Okay...

Olivia: Let's say we declare it as <!ELEMENT university (building+, address, student*, brewery?)>. What does that mean?

James: Hmm, okay. The + on building means it must have at least one building. address has no symbol, so exactly one address. student* means it can have zero students, or many.

Olivia: Perfect! And the last one?

James: brewery?... so I guess a brewery is optional? Probably for the best.

Olivia: Exactly! The DTD enforces that a university without a building is invalid, but one without a brewery is perfectly fine.

James: That makes sense. But elements often have attributes, like an id or a src link. How do we define those rules?

Olivia: For that, we use the <!ATTLIST ...> declaration. It lets you define all the attributes for a specific element.

James: So you'd have one ATTLIST for the img tag, another for the student tag, and so on.

Olivia: You got it. And just like with elements, you define the type of content the attribute can hold.

James: Is it just text?

Olivia: The most common type is CDATA, which is basically just a string of text. But there are more powerful types. For example, the ID type.

James: Let me guess... it has to be a unique ID within the entire document?

Olivia: Exactly! It's like a primary key in a database. No two elements can have an attribute of type ID with the same value.

James: And I see IDREF here too. Is that like a foreign key?

Olivia: It is! An attribute with type IDREF must contain a value that matches an ID from somewhere else in the document. It's how you create relationships and links between elements.

James: So when you're defining attributes, can you make them mandatory?

Olivia: Absolutely. After you define the attribute's type, you specify its necessity. You can use #REQUIRED, which means it must be included.

James: And if it's optional?

Olivia: Then you use #IMPLIED. There's also #FIXED, which means the attribute must have a specific, unchangeable value. That's often used for things like version numbers.

James: Okay, one last thing... what are entities?

Olivia: Think of entities as variables or shortcuts. You can declare an entity, give it a name, and assign it a long piece of text. Then, you can just use the entity's name in your document, and the parser will substitute in the full text. It's great for reusable content like a page footer.

James: So it's a way to keep your code DRY—Don't Repeat Yourself.

Olivia: Even in XML! That's the perfect way to think about it.

James: Awesome. Well, that's a fantastic deep dive into DTDs. So to quickly recap our whole discussion today... we've covered the core structure of XML, learned how to validate it with DTDs, and defined everything from elements and their occurrences to attributes and entities.

Olivia: We really did. The key takeaway is that structure and validation are what make XML so powerful and reliable for data exchange.

James: It's been incredibly insightful, Olivia. A huge thank you for breaking it all down for us.

Olivia: My pleasure, James! It was a lot of fun.

James: And a huge thank you to all of our listeners for tuning in to the Studyfi Podcast. We hope this helps you ace your exams. Until next time, keep learning!