Zasady wprowadzania znaczników
Analizując dokumenty strukturyzowane, poznajemy zasady wprowadzania znaczników do tekstu: tagów nie wolno krzyżować, każde otwarcie tagu musi mieć odpowiadające mu zamknięcie. Zasady i ich restrykcyjność są różne dla dokumentów HTML i XML.
Każdy dokument XML musi bezwzględnie stosować się do zasad, aby został poprawnie przetworzony i zaakceptowany przez parser (program sprawdzający poprawność, składnię i strukturę każdego generowanego dokumentu). Język XML musi odpowiadać wyższym standardom i nie może zawierać „śmieciowych” błędów, które z reguły nie przeszkadzają w poprawności zapisu w formacie HTML. Dzięki temu dokumenty XML są czytelne i użyteczne nie tylko obecnie, ale będą zawsze, niezależnie od zmieniających się standardów zapisu, nowych technologii i nowych rozwiązań informatycznych.
Jako przykład możemy przedstawić wykorzystanie tagu zrzucenia tekstu do następnego wiersza w postaci <br>. Przez wiele lat przeglądarki internetowe i parsery HTML akceptowały jego istnienie w postaci <br>. Zgodnie z zasadami języków znakowanych każdy tag, który nie zawiera treści, oznacza początek i koniec, powinien występować w formacie ze slashem na końcu czyli <br/>. Po przejściu do bardziej wymagającego standardu xHTML, dokumenty z tagiem typu <br> przestały się poprawnie parsować. W celu uniknięcia podobnych problemów, XML nie pozwala na żadne odstępstwa, a poprawności zapisu pilnują rygorystyczne parsery.
Prawidłowo, poprawnie oraz nieprawidłowo sformułowany dokument
- Prawidłowy dokument zgodny zarówno z regułami składni XML, jak i regułami plików kontrolnych takich jak DTD czy schema.
- Poprawny dokument zgodny z regułami składni XML, ale nie mający definicji DTD czy schema (wersja uboższa).
- Nieprawidłowy dokument – niezgodny z regułami składni określonymi w specyfikacji XML oraz plikami kontrolnymi DTD czy schema zdefiniowanymi przez programistę.
Element główny dokumentu
Każdy dokument XML w całości musi być zawarty w elemencie głównym, okalającym zarówno czysty tekst jak i jego strukturę.
Oto przykłady prawidłowego i nieprawidłowego dokumenty zapisanego w standardzie XML:
<?xml version="1.0"?> <!—Poprawnie sformatowany dokument --> <greeting> Miłego dnia! </greeting>
Cały dokument XML umieszczony jest w nadrzędnym elemencie: <greeting>…</greeting>. <!—Poprawnie sformatowany dokument --> to dopuszczalny w takim trybie zapisu komentarz
<?xml version="1.0"?> <!—Niepoprawnie sformatowany dokument --> <greeting> Miłego dnia! </greeting> <greeting> Have a nice day! </greeting>
W tym dokumencie tag <greeting> pełni w strukturze funkcję podrzędną, natomiast tag nadrzędny w ogóle nie został zdefiniowany. Parser XML odrzuci taki dokument jako nieprawidłowy, ponieważ, aby był poprawny, musi mieć zdefiniowany nadrzędny element obejmujący wszystkie pozostałe.. Z reguły stosuje się elementy <root> lub <content>, które pozwalają logicznie wydzielić treść od np. instrukcji przetwarzania czy komentarzy zawartych w nagłówku.
Znaczniki nie mogą się krzyżować
Oto kilka przykładów nieprawidłowego i prawidłowego wprowadzenia znaczników:
<!—Niepoprawne oznakowanie XML --> <p> <b>1. <i>Droga do wolności</b> jest trudna. </i> </p>
W poprawnej strukturze XML znacznik <i> zagnieżdżony wewnątrz znacznika <b>, musi zostać zamknięty przed zamknięciem znacznika <b>. Jeśli tekst po zamknięciu <b> ma nadal być kursywą, znaczniki <i> i </i> muszą być powtórzone po zamknięciu <b>.
<!—Poprawne oznakowanie XML --> <p> <b>1.<i>Droga do wolności</i></b> <i>jest trudna.</i> </p>
Plik kontrolny składni XML (parser) będzie akceptował tylko tę poprawną strukturę znaczników, natomiast parser HTML uzna oba zapisy, przynajmniej w niektórych przeglądarkach internetowych, za prawidłowe. Struktura dokumentu XML musi być budowana bardzo restrykcyjnie, ponieważ żadne błędy nie zostaną przepuszczone, stąd wartość i użyteczność takiego dokumentu jest ogromna.
Powodem takich różnic między formatami HTML i XML jest ich projektowane zastosowanie. Celem HTML jest pokazanie odbiorcy strony internetowej właściwie za wszelką cenę. Format ten powstał i był rozwijany w taki sposób, by niemal każdy był w stanie stworzyć swoją stronę internetową. XML powstał jako język baz danych treści, zatem od początku wszystkie dokumenty w nim stworzone musiały zachowywać najwyższe standardy. Wraz z rozwojem internetu język HTML coraz bardziej przybliżał się do standardu XML (Extensible Markup Language), czego wyrazem jest obowiązujący obecnie w internecie standard xHTML (Extensible HyperText Markup Language).
Znaczniki muszą mieć początek i koniec
W strukturze dokumentu każdy tag otwierający musi mieć swój odpowiednik zamykający. Jedyna poprawna definicja to <…>tekst</…>.
<!—Niepoprawne oznakowanie XML --> <p>Pada deszcz... <p>Jutro będzie świecić słońce... <p>.
W powyższym przykładzie brakuje tagów zamykających przejścia do następnego akapitu (</p>). W dokumencie zapisanym w standardzie HTML jest to dopuszczalne (również w niektórych przypadkach SGML), natomiast parser XML go odrzuci.
W strukturze XML dopuszczalne są elementy puste. W dokumentach HTML tagi puste typu <br> (nowa linia) lub <img> (informacja o ilustracji przypisanej do tego fragmentu tekstu), bez zamknięcia, są dla plików kontrolnych (parsera) akceptowalne. W dokumentach XML tag pusty, o ile występuje pojedynczo, musi zawierać ukośnik <br/>.
<!—Dwa równoznaczne zapisy tagów --> <br></br> <!— lub --> <br/>
<!—Dwa równoważne elementy ilustracja --> <img src="../img/c.gif"></img> <!— lub --> <img src="../img/c.gif"/>
W nazwach znaczników istotna jest wielkość liter (case sensitive)
W strukturach HTML wielkość liter w nazwie znaczników nie ma znaczenia: Tag <h1> czy <H1> oznacza to samo – tytuł pierwszego rzędu, obie formy zostaną potraktowane równoważnie. Czyli otwarcie <h1> i zamknięcie </H1> jest akceptowalnym zapisem. W dokumentach XML wielkość liter ma znaczenie dla poprawności dokumentu, tagi muszą być nazwane jednolicie.
<!—Niepoprawny dokument XML --> <h1>Świat jest piękny</H1>
<!—Poprawny dokument XML --> <H1>Świat jest piękny</H1>
Atrybuty w znacznikach muszą mieć podane wartości
Rolą atrybutów umieszczanych wewnątrz tagów jest uściślenie informacji na temat wybranego fragmentu tekstu. Za pomocą atrybutów można ustalać stopień ważności, położenie geograficzne, kolor, epokę, gatunek… dowolna definicja, która z punktu widzenia zaplanowanej struktury, jest istotna dla selekcjonowania i wyszukiwania informacji w budowanej publikacji. Listy atrybutów i ich przypisanie do konkretnego tagu są tworzone przez twórcę projektu, zgodnie z założeniami dalszego wykorzystania dokumentu.
Istotne są dwie reguły dla wprowadzania atrybutów wewnątrz tagu w dokumentach XML:
- Atrybuty muszą mieć podane wartości liczbowe lub tekstowe
- Wartości te muszą być ujęte w cudzysłowy
Znaczniki bez podanych wartości są poprawne w HTML, ale nie w XML. Znacznik z atrybutem w dokumencie XML musi mieć wpisaną wartość ujętą w cudzysłowach.
<!—Niepoprawne występowanie atrybutu w znaczniku XML --> <H1 color>
<!—Poprawny występowanie atrybutu w znaczniku XML --> <H1 color="czerwony">
To, jak ważne są atrybuty, pokazuje rozwój języka HTML. Wiele znaczników, tradycyjnie stosowanych w języku HTML, zostało zamienionych w języku xHTML na atrybuty. Stopniowo odchodzi się nawet od tak popularnych znaczników jak <u> (podkreślenie) czy <b> (bold) zastępując je tagiem span opatrzonym odpowiednimi atrybutami, np. <span style=”text-decoration: underline”> (podkreślenie) czy <span style=”font-weight: bold”>.
Przykłady:
Gatunek muzyczny: <song genre="rock"></song>
Styl: <painting style="abstract"></painting>
Marka: <car brand="Mercedes"></car>lub <computer brand="ibm"></computer>
Pochodzenie: <coffee origin="Columbia"></coffee>
Słownik: <book type=”dictionary”></book>
Teoretycznie można te same informacje przekazać za pomocą znaczników, np.
<book type=”dictionary”></book>
może w następujący sposób zostać przetworzone przez bazę danych:
<book> <type>dictionary</type> </book>
Z punktu widzenia wydawcy kluczowe znaczenie ma fakt, że zależnie od formy zapisu elementu, w programach DTP tekst będzie się wyświetlać w treści dokumentu lub pokazywać jako informacja wewnątrz tagu. InDesign zinterpretuje atrybut type i pokaże go w drzewku (cierpliwym umożliwi nawet jego zmianę), a ten sam tekst zapisany pomiędzy tagiem otwarcia i zamknięcia wyświetli go na początku ramki tekstowej. Przy zachowaniu odpowiedniego formatowania treści można przekazać ją do programu typu InDesign, przełamać np. do formatu PDF i zwrócić bez strat strukturalnych do bazy danych.
Deklaracje XML
Dokument XML powinien, choć nie musi, zawierać techniczne informacje o tworzonym dokumencie:
- wersja używanego XML (1.0; 1.1),
- system kodowania znaków (ISO-8859-1; Unicode),
- wyróżnik samodzielny (standalone yes; no).
Wersja wykorzystanego standardu XML. W związku z postępem technologicznym w zakresie stosowanych narzędzi, wykorzystana wersja XML to istotna informacja dla oddalonego w czasie przetwarzania tworzonego dokumentu. Umieszczenie jej w nagłówku dokumentu przyspiesza identyfikację.
System kodowanie znaków. Jeśli zestaw kodowania liter nie zostanie zdefiniowany, plik kontrolny (parser) dokumentu uzna, że znaki są zgodne z zestawem UTF-8 (Unicode). Jeśli jednak zostanie zastosowany inny zestaw (np. ISO-8859-1), należy jego nazwę umieścić w informacji wstępnej, aby dokument został poprawnie zinterpretowany.
Wyróżnik samodzielny (standalone). Jest to informacja, czy tworzony dokument będzie przetwarzany bez stosowania reguł plików kontrolnych, czy też jego poprawność będzie kontrolowana przez dodatkowe pliki zdefiniowane jako DTD czy schema. Zapis standalone=”yes” oznacza, że dokument XML nie odwołuje się do żadnych plików kontrolnych. Standalone=”no” jest wyróżnikiem domyślnym, oznaczającym, że struktura jest analizowana przez pliki kontrolne, nie trzeba więc jej umieszczać w deklaracjach wstępnych. Szczegółowo o plikach kontrolnych będzie mowa w kolejnym rozdziale.
Poprawna deklaracja wstępna:
<? xml version = "1.0" encoding = "ISO-8859-1" standalone = "no"?>
Inne informacje zawarte w dokumentach XML
Komentarze. Komentarze można umieszczać w dowolnym miejscu w dokumencie. Treść komentarza oraz wszystkie znaki umieszczone wewnątrz, są ignorowane przez strukturę. Można wpisać dowolny tekst korespondencyjny w środku dokumentu, np. tekst do dalszego rozwinięcia; fragment do usunięcia w konkretnej sytuacji (należy ten fragment oznaczyć na początku i końcu stosowanym komentarzem. Po usunięciu komentarza tekst zostaje przywrócony); preferowane ustawienia itp. Jest to rodzaj wewnętrznych notatek tworzonych do komunikowania się pomiędzy uczestnikami projektu lub formą wprowadzenia istotnej danej dla twórcy dokumentu. Komentarz zawiera informacje, które stanowią wartość dodaną dla interpretacji dokumentu, ale nie stanowią jego treści. Osiągnięcie powyższego efektu wymaga bardzo ścisłego dostosowania się do procedury zapisu komentarza. Treść komentarz zaczyna się od <! - i kończy na ->, nie może zawierać podwójnego myślnika wewnątrz.
Oto właściw forma zapisu komentarza:
<person> <name>Andrzej</name> <surname>Nowak</surname> <!-- TODO: Nie mam pewności, czy podany numer telefonu jest aktualny --> <phone>221231231</phone> </person>
Instrukcje przetwarzania. Instrukcja przetwarzania jest znacznikiem przeznaczonym dla określonego fragmentu kodu. W powyższym przykładzie istnieje instrukcja przetwarzania (czasami nazywana PI) dla Cocoon, struktury przetwarzania XML z Apache Software Foundation. Kiedy Cocoon przetwarza dokument XML, szuka instrukcji przetwarzania, które zaczynają się od procesu Cocoonu, a następnie przetwarza dokument XML odpowiednio. W składni atrybut type = „sql” informuje Cocoon, że dokument XML zawiera instrukcję SQL. Dzięki temu bezpośrednio w strukturze XML można przechowywać elementy innych języków programowania lub baz danych.
<!—To jest instrukcja dla Cocoon: --> <?cocoon-process type = "sql"?>
Encje. Encja to definicja litery akcentowanej lub znaku specjalnego, która umożliwia ich łatwą i jednoznaczną interpretację w każdym języku świata. Ciąg znaków rozpoczynających się od &…; zostanie odczytany jako encja, np. ą oznacza ą, ł ł. W postaci encji zapisywane są znaki używane do definiowania encji i tagów, np. & &; < <; > >; " „.
W standardzie Unicode encje nie mają postaci opisowej, lecz numeryczną. UNICODE entities jest międzynarodowym system zapisu. Znana z podglądu fontów fraza „Zażółć gęślą jaźń” zapisana w postaci encji Unicode będzie wyglądać następująco: Zażółć gęślą jaźń. W postaci encji zapisywane są wszystkie znaki nie występujące w podstawowej tablicy znaków. Dzięki temu można w jednym dokumencie stosować dziesiątki języków oraz przekazywać dokumenty w dowolne miejsce świata przy zachowaniu pewności, że przy wczytaniu wszystkie znaki, nawet najbardziej „regionalne”, zostaną wczytane poprawnie.
Przestrzenie nazw
Potęga XML jest rezultatem elastyczności zapisu struktury dokumentu – każdy definiuje własne zasady zapisu dokumentu zgodnie z potrzebami jego dalszego wykorzystania i przetwarzania. Należy tu przywołać przykładowy dokument XML definiujący nazwiska i adresy osób. Dokument ten zawiera element <title> będący grzecznościowym tytułem osoby. Natomiast księgarnia internetowa, stworzy element <title> dla tytułu książki, a firma oferującą kredyty hipoteczne online, stworzy element <title> dla tytułu własności nieruchomości. Znaczniki te są poprawne strukturalnie, ale każdy z tych elementów o tej samej nazwie niesie zupełnie inne treści merytoryczne. Jak określić, czy dany element <title> odnosi się do osoby, książki czy części nieruchomości? Do tego właśnie służą przestrzenie nazw.
Aby użyć przestrzeni nazw, należy zdefiniować prefiks przestrzeni nazw i odwzorować go na określony ciąg. Oto jak możesz zdefiniować prefiksy przestrzeni nazw dla naszych trzech elementów <title>:
<?xml version="1.0"?> <customer_summary xmlns:addr="http://www.xyz.com/addresses/" xmlns:books="http://www.zyx.com/books/" xmlns:mortgage="http://www.yyz.com/title/" > ... <addr:name><title>Mrs.</title> ... </addr:name> ... ... <books:title>Lord of the Rings</books:title> ... ... <mortgage:title>NC2948-388-1983</mortgage:title> ...
W tym przykładzie trzy prefiksy przestrzeni nazw to addr, books i mortage. Zdefiniowanie przestrzeni nazw dla określonego elementu oznacza, że wszystkie jego elementy potomne należą do tej samej przestrzeni nazw. Pierwszy element <title> należy do przestrzeni nazw addr, ponieważ jego elementem nadrzędnym jest <addr: Name>
Ostatni punkt: ciąg w definicji przestrzeni nazw jest po prostu ciągiem, wygląda jak adresy URL, ale tak nie jest. Można zdefiniować xmlns:addr=”mike” i to będzie działa ć równie dobrze. Najważniejszą rzeczą w łańcuchu przestrzeni nazw jest fakt, że jest on unikatowy i z tego powodu większość definicji przestrzeni nazw wygląda jak adresy URL.. Analizator składni XML nie trafia do http://www.zyx.com/books/ w celu wyszukania DTD lub schema, po prostu używa tego tekstu jako ciągu.
Dobrym przykładem zastosowania przestrzeni nazw w wydawnictwie będzie zdefiniowanie trzech przestrzeni: albumów, książek oraz słowników. Do każdej z tych przestrzeni zostanie przypisany inny zestaw reguł poprzez plik kontrolny. W każdej z nich będzie występował element <ilustracja>. Ze względu na odmienną charakterystykę poszczególnych rodzajów publikacji, element ten będzie miał inne wymogi i miejsce w strukturze w każdej z nich.
<album:ilustracja> będzie zatem odnosił się do elementu, który może (ale nie musi) posiadać podpis i może znajdować się w strukturze bezpośrednio (a nie jako element jakiegoś innego kontenera, czyli elementu zawierającego inne elementy).
<ksiazka:ilustracja> będzie się odnosić do elementu, który musi posiadać podpis i musi znajdować się wewnątrz akapitu, którego dotyczy.
<slownik:ilustracja>będzie dotyczyć elementu będącego elementem hasła.
Analizując strukturę słownika parser sprawdzi, czy ilustracja znajduje się wewnątrz hasła, a badając strukturę książki sprawdzi, czy po ilustracji na pewno występuje element <podpis> itp.
Co ciekawe, wewnątrz jednego pliku można zastosować wiele przestrzeni. Dzięki temu możliwe jest, na podstawie kwerendy czytelnika, wyeksportowanie wybranych tematów ze wszystkich zarchiwizowanych publikacji zachowując spójność i poprawność wyeksportowanego dokumentu. Przy zachowaniu odpowiedniej formy zapisu, tę informację można później przetworzyć np. na stronę internetową poprzez plik CSS, który tak samo otagowane elementy sformatuje w różny sposób zależnie od tego, w jakiej przestrzeni nazw występują.