Pobierz prezentację
Pobieranie prezentacji. Proszę czekać
1
Polsko-Japońska Wyższa Szkoła Technik Komputerowych
Technologie Internetu wykład 8: Document Type Definitions oraz XML Schema Piotr Habela Polsko-Japońska Wyższa Szkoła Technik Komputerowych 1
2
W poprzednim odcinku… Języki znaczników – SGML jako protoplasta HTML i XML Działalność World Wide Web Consortium (W3C): Zasady projektowe specyfikacji: współdziałanie, ewolucyjność, decentralizacja. Wizja rozwoju Web-u: od prostej architektury (URL, HTTP, HTML), po rozbudowany system standardów opartych na URI, HTTP 1.1 i XML. Składnia języka XML: Element i jego atrybut; Encja; Deklaracja (sekcja znakowa, komentarz, inne…); Poprawność składniowa dokumentu XML; Poprawność strukturalna dokumentu XML. 2
3
Plan wykładu Przydatność definicji typu dokumentu.
Document Type Definition (DTD): Sposoby umieszczania; Deklarowane właściwości; Ograniczenia. XML Schema – wprowadzenie. 3
4
Motywy dla definiowania typu dokumentu
Skuteczniejsza kontrola błędów przy tworzeniu dokumentu oraz możliwość zaimplementowania podpowiedzi w edytorach XML. Możliwość uzgodnienia formatów dla elektronicznej wymiany dokumentów pomiędzy instytucjami. Definiowanie sposobów konwersji pomiędzy dokumentami sporządzonymi w różnych formatach. Podstawa dla określania sposobów wizualizacji poszczególnych rodzajów elementów. 4
5
Poprawność strukturalna dokumentu XML
Warunek konieczny – poprawność składniowa. Prolog zawierający deklarację DTD albo odwołanie do zewnętrznej DTD. Pozostała zawartość dokumentu zgodna z podanym DTD. Co może zawierać prolog ? Tzw. deklarację XML (określa użytą wersję XML, sposób kodowania znaków oraz samodzielność dokumentu). Deklaracje typu DTD. Pomiędzy ww. mogą występować instrukcje przetwarzania (PI – Processing Instruction) oraz rozdzielające „znaki białe” (whitespace). 5
6
Tworzenie Definicji Typu Dokumentu
Definicja wewnętrzna: w postaci pojedynczego bloku DOCTYPE zwanego deklaracją typu dokumentu (document type declaration): <!DOCTYPE nazwaTypu [ …….. ]> Wewnątrz nawiasów kwadratowych znajduje się deklaracja przynajmniej jednego elementu – stanowiącego element-korzeń dokumentu. Wyróżnia go nazwa identyczna z nazwą typu dokumentu. Np. <!DOCTYPE jakisTekst[ <!ELEMENT jakisTekst (#PCDATA)> ]> Definicja zewnętrzna: zamiast definicji elementów umieszczanej wewnątrz nawiasów kwadratowych, występuje odwołanie do zewnętrznego pliku: <!DOCTYPE nazwaTypu SYSTEM ”osobnyPlik.dtd”> Definicje zewnętrzna i wewnętrzna: jako pierwsza zostanie przetworzona lokalna i jej deklaracje mogą przesłonić (przedefiniować) te pobrane z zewnętrznego pliku. 6
7
Definicja typu zewnętrzna
Identyfikator systemowy: Po słowie kluczowym SYSTEM występuje identyfikator zasobu (URI). Zwykle jest to względny lub bezwzględny adres URL. Identyfikator publiczny: Zamiast słowa kluczowego SYSTEM występuje PUBLIC, a następnie, przed identyfikatorem zasobu występuje dodatkowo tzw. FPI (Formal Public Identifier), o następującej budowie (segmenty rozdzielone są podwójnymi ukośnikami: „//”): znak + oznaczający definicję stanowiącą standard lub – oznaczający definicję nie będącą standardem; nazwa instytucji odpowiedzialnej za specyfikację typu; typ dokumentu i nr wersji; dwuliterowy kod oznaczający język; Np. <!DOCTYPE faktura_XYZ PUBLIC "-//Firma XYZ//Faktura 1.0//PL" " Zob. też: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"> 7
8
Deklarowanie elementów
Budowa deklaracji elementu: słowo kluczowe ELEMENT; nazwa elementu (nazwa identyfikujących go znaczników); definicja zawartości. Model zawartości elementu: zawartość znakowa (tekst); zawartość elementowa (określonego rodzaju podelementy); zawartość mieszana. 8
9
Elementy proste Definicja zawartości dla elementu prostego:
deklaracja elementu pustego: EMPTY; deklaracja dowolnej zawartości: ANY; deklaracja zawartości tekstowej: (#PCDATA); Skrót od: Parsed Character Data. Np. <!ELEMENT tekstowy (#PCDATA)> <!ELEMENT paragraf ANY> <!ELEMENT separator EMPTY> Zastosowanie elementów pustych: jako miejsce przechowywania atrybutów; jako przełącznik dla programów przetwarzających. Deklaracja zawartości dowolnej (ANY): Dowolne, ale zdefiniowane podelementy; Zawartość ta (podelementy) dowolnie poprzeplatana zwykłym tekstem. 9
10
Zawartość elementowa W najprostszej postaci, jest to nazwa elementu zawieranego (podelementu) ujęta w nawias; Oznacza to dokładnie jedno wystąpienie takiego podelementu; Tę liczność można modyfikować symbolami: „+” oznacza [1..*], „?” oznacza [0..1], „*” oznacza [0..*]. Nazwy podelementów (wraz z określeniemi ich liczności) można grupować za pomocą: symbolu przecinka => oznacza sekwencję, symbolu „|” => oznacza wybór dokładnie jednego z rozdzielonych tak elementów; W oparciu o powyższe konstrukcje można tworzyć złożone deklaracje używając nawiasów: <!ELEMENT firma ((oddział)+ | przedstawicielstwo)> <!ELEMENT oddział (dyrektor, handlowiec*, osoba_kontaktowa?)> 10
11
Zawartość mieszana Może stanowić albo sam tekst (co sprowadza się do zawartości tekstowej), … albo dowolna liczba powtórzeń tekstu i podelementów; Istnieje istotne ograniczenia na postać deklaracji. Efektywnie jedyna dozwolona postać deklaracji to: <!ELEMENT nazwaMieszanego (#PCDATA | element_1 | element_2)*> Czyli, dla takiej grupy wyboru nie można ani pominąć symbolu liczności „*”, ani użyć innego (tj. „?” ani „+”). Jako pierwszy element wyboru musi ponadto zawsze wystąpić #PCDATA. 11
12
Zawartość elementowa - niedogodności
Podstawową trudnością jest zadeklarowanie jako możliwej zawartości elementowej podzbioru z jakiegoś repertuaru dokumentów. Np. konieczność umieszczenia dwóch dokumentów tożsamości, spośród kilku zdefiniowanych rodzajów => potrzeba zadeklarować osobno każdą dwuelementową kombinację: <!ELEMENT tozsamosc ((dowod_osobisty | prawo_jazdy) | (dowod_osobisty, paszport) | (prawo_jazdy, paszport) | (dowod_osobisty, indeks) | (prawo_jazdy, indeks) | (paszport, indeks))> Sekwencja dwóch wyborów byłaby o wiele bardziej zwięzła, ale niestety nie wykluczyłaby powtórzeń. Gdyby należało ponadto zapewnić dowolność kolejności umieszczania takich elementów, to rozmiar deklaracji dodatkowo znacznie wzrósłby. 12
13
Deklaracje atrybutów Atrybuty występują w postaci par nazwa=”wartość” w otwierających znacznikach XML. Deklaracje atrybutów dla danego rodzaju elementu zawarte są w deklaracji ATTLIST odnoszącej się do nazwy opisywanego elementu. Definicja atrybutu składa się z: nazwy atrybutu i typu atrybutu; wartości domyślnej (lub określenia obowiązkowości występowania). np. <!ELEMENT opis (#PCDATA)> <!ATTLIST opis id ID #IMPLIED kto_wprowadzil CDATA #IMPLIED> Zadeklarowano tu element o zawartości tekstowej, który posiada dwa opcjonalne atrybuty: unikalny identyfikator (typ ID) oraz tekst identyfikujący osobę która wprowadziła element. 13
14
Atrybuty w XML – dostępne typy
CDATA – łańcuch znaków; ID – unikalna wartość w ramach całego dokumentu. Każdy element może posiadać tylko jeden atrybut takiego typu. Nie może zawierać białych znaków. IDREF – odnośnik do identyfikatora. Prosty rodzaj odsyłacza. IDREFS – zbiór odsyłaczy do identyfikatorów (rozdzielony spacjami). NMTOKEN – pojedyncze słowo – symbol (tylko litery cyfry i wybrane znaki jak „_” „-” czy kropka). NMTOKENS – zbiór słów – symboli. ENTITY – encja; ENTITIES – zbiór encji (rozdzielony spacjami); NOTATION – instrukcje podlegające innym regułom składniowym niż XML. wyliczeniowy – lista wartości w podana w nawiasie i rozdzielona symbolami „|”. xml:nazwa – jako nazwa atrybutu determinuje zbiór jego wartości (zdefiniowany standardem z rodziny XML). 14
15
Wartości domyślne atrybutów
Po specyfikacji typu może wystąpić: Wartość domyśna: ”wartość” Oznaczenie opcjonalności atrybutu (domyślne, jeśli nie zostało podane inaczej): #IMPLIED Oznaczenie obowiązkowości atrybutu: #REQUIRED Określenie atrybutu jako stałej: #FIXED ”wartość”. Naturalnie, wszystkie te opcje wzajemnie się wykluczają. 15
16
Jak modelować właściwości elementu?
Jako atrybuty czy jako podelementy? Kryteria wyboru: charakter umieszczanych danych (cechy charakteryzujące cały element => atrybuty; spójne obiekty podrzędne wobec naszego elementu => podelementy); ograniczenia narzucone przez konstrukcję języka. Stosowanie podelementów: informacja pojęciowo separowalna jako spójny obiekt; informacja może się powtarzać (kilka egzemplarzy w naszym dokumencie); istotna jest kolejność. Stosowanie atrybutów: informacje dodatkowe, współzależne z podelementami (np. liczba rozdziałów); użycie typu wyliczeniowego dla wartości (np. status dokumentu); informacja o stałej wartości; istotna jest niepowtarzalność wartości (użycie ID jako typu atrybutu). 16
17
Przestrzenie nazw (namespaces)
Umożliwiają bezkolizyjne korzystanie z niezależnie powstałych definicji elementów i ich atrybutów. Deklarowane w postaci: xmlns:NASZ_PREFIKS=” URI nie musi wskazywać na plik z definicją typu dokumentu; jedynie unikalnie identyfikuje daną przestrzeń nazwową. Zaleca się, aby w tym celu nie stosować względnych adresów URL. Deklaracja zwykle jest zlokalizowana jako atrybut w korzeniu dokumentu, jako że obowiązuje wówczas dla wszystkich elementów podrzędnych. Użycie: NASZ_PREFIKS:nazwaElementu Prefiks xml jest zarezerwowany: predefiniowane atrybuty (xml:lang, xml:space, xml:base) -> zob. dalej. 17
18
Domyślne i predefiniowane przestrzenie nazwowe
Domyślna przestrzeń nazwowa: nie wymaga prefiksowania jej elementów w ciele dokumentu; deklarowana w postaci xmlns= URI (czyli też bez prefisku). Przestrzenie standardowe: html -> HTML oraz XHTML; xlink -> XLink; xsd -> XML Schema; xsl -> XSLT; fo -> XSL; mml -> MathML; svg -> SVD; rdf -> RDF; rdfs -> RDF Schema; ds -> XML Signature. Zakłada się, że aplikacja obsługująca dany język standardowy będzie posiadała wbudowaną jego definicję. Z kolei dla innych języków URI stanowi zwykle zarazem adres definicji DTD. 18
19
Atrybuty predefiniowane języka XML
xml:lang -> język (narodowy) zawartości danego dokumentu. Podawany jako dwuliterowy kod wg normy ISO-639, uzupełnione opcjonalnie (według ISO-3166) o dwie litery oddzielone pauzą (wersja języka); np. en-US i en-GB. Kody niestandardowe rozpoczyna „x-”. xml:space -> określa sposób traktowania białych znaków. Przybiera wartości: ”default” lub ”preserve”. W tym drugim wypadku znaki białe wewnątrz danego elementu nie będą redukowane. Obydwa atrybuty należy zadeklarować w definicji typu elementu (możliwe, że jako stałe lub z wartością domyślną), którego będą dotyczyć. np. <!ATTLIST faktura xml:lang NMTOKEN ”pl”> xml:base -> określa adres URI odniesienia dla adresów względnych. Powtórne zdefiniowanie tego atrybuty w elemencie podrzędnym spowoduje, że w jego wnętrzu będzie obowiązywało złożenie obu ścieżek. 19
20
Encje (entities) – zastosowanie i rodzaje
Umożliwiają wyodrębnianie i odwoływanie się do nazwanych elementów XML. Encje ogólne przetwarzane: odwołania w postaci &nazwaEncji; wewnętrzna: treść zawarta w deklaracji encji; Np.: <!ENTITY pjwstk ”Polsko-Japońska Wyższa Szkoła Technik Komputerowych”> zewnętrzna: treść zawarta w zewnętrznym dokumencie; <!ENTITY tekstNaglowka SYSTEM "naglowek.txt"> (mechanizm jednostek zewnętrznych rozwijany jest jako XML Inclusions (Xinclude)) Ogólna zewnętrzna nieprzetwarzana: inna postać odwołania – nazwa encji jako wartość atrybutu. Zawiera etykietę NDATA a za nią nazwę formatu. Np. <!ENTITY logo SYSTEM ”NaszeLogo.jpg” NDATA obraz_jpg> 20
21
Encje - rodzaje Parametryczna: oznaczana symbolem %. Odwołania do niej mogą występować tylko w ramach tego samego DTD. Służą określaniu powtarzających się w danym DTD treści. wewnętrzna: treść w deklaracji DTD; Np. <!ENTITY % atrybuty_adresowe ”ulica CDATA #REQUIRED miejscowosc CDATA #REQUIRED kraj CDATA #IMPLIED”> zewnętrzna: treść w zewnętrznym pliku DTD. Służy dekompozycji dużego DTD pomiędzy kilka plików. Np. <!ENTITY % definicja_cennika SYSTEM ”cennik.dtd”> <!ENTITY % faktura PUBLIC ”-//Nasza Firma//format faktury 1.1//PL” ”faktura.dtd”> Wykorzystanie w DTD: %nazwaEncji; 21
22
Deklaracja notacji (notation)
Służy określeniu zawartości o składni różnej od XML. Innymi słowy – może określać: format nieprzetwarzanych encji; format elementów; aplikacja przetwarzająca daną instrukcję przetwarzania (PI); Składa się z nazwy formatu i z adresu przetwarzającego go oprogramowania (możliwy też identyfikator publiczny): <!NOTATION obraz_jpg SYSTEM ”../apps/viewer.exe”> Wykorzystanie w deklaracji nieprzetwarzanej encji zewnętrznej: <!ENTITY logo SYSTEM ”NaszeLogo.jpg” NDATA obraz_jpg> Odwołanie do encji nieprzetwarzanej następuje poprzez jej nazwę w odpowiednim atrybucie: <rysunek zawartosc=”logo” /> 22
23
Pozostałe konstrukcje
Fragmenty deklaracji można ująć w deklarację sekcji warunkowej: <![INCLUDE [ ….. ]]> Zamiana słowa kluczowego na IGNORE spowoduje pominięcie danego fragmentu deklaracji. Tę podmianę można wspierać encjami parametrycznymi. Deklaracja samodzielności dokumentu (standalone declaration) – umieszczana w deklaracji XML. Deklaracja taka jest potrzebna z następujących przyczyn: deklaracje znaczników (markup declarations) zawarte w DTD mogą wpływać na postać dokumentu (np. wartości domyślne atrybutów, deklaracje encji); jeśli deklaracje są zawarte w zewnętrznym DTD, to przez tzw. parser niewalidujący (czyli parser nie sprawdzający poprawności strukturalnej) zostają pominięte; Wobec tego wartość standalone=”no” zmusza do sięgnięcia do tych definicji. 23
24
Ograniczenia DTD Określenie zawartości elementu jako tekstowej powoduje pełną dowolność co do jego zawartości; Elementy nie mogą określać wartości domyślnych; Brak ograniczenia na unikalność wartości atrybutu; Brak ograniczenia na unikalność zawartości elementu; Słabe możliwości kontroli typów; Brak możliwości odrębnego definiowania typów wykorzystywanych w różnych miejscach; brak dziedziczenia; Niemożność ustalenia kolejności atrybutów; Niemożność zmiany kolejności elementów; Przestrzenie nazwowe nie są wspierane w DTD; Rozbieżności składniowe w stosunku do zwykłego XML. 24
25
XML Schema Projektowany jako uzupełnienie czy wręcz następca DTD (w przeciwieństwie do niego jest odrębnym językiem). Jest w stanie swymi deklaracjami odwzorować dowolną definicję DTD, jednak nie odwrotnie. Bardzo rozbudowana specyfikacja. Wydana w 2 częściach: Struktury (Structures) oraz Typy Danych (Datatypes). Znacznie bardziej rozbudowany system typów. Możliwość nakładania różnych ograniczeń na dopuszczalne wartości i ich unikalność. Wyprowadzanie nowych typów z już istniejących: mechanizm rozszerzeń (extensions) i ograniczen (constraints). Uwzględnienie przestrzeni nazw w definicji schematu. I inne… 25
26
Deklaracja schematu dokumentu
W przeciwieństwie do DTD, XML Schema jest osobnym językiem, więc należy wyspecyfikować jego przestrzeń nazwową. Przypomnijmy, że przewidziano dlań prefiks xsd. Deklaracja wygląda więc następująco: <xsd:schema xmlns:xsd=" .... </xsd:schema> Stosowanie dokładnie tego prefiksu nie jest obowiązkowe (można wybrać inny albo domyślny). Z kolei konieczne jest, aby korzeń definicji był element o nazwie „schema”. Deklaracja elementu: <xsd:element name=”nazwaElementu” type=”xsd:string” /> Zwróćmy uwagę na typową składnię XML oraz możliwość przypisania precyzyjnie określonego typu zawartości elementu. 26
27
Zawartość definicji schematu
Sposób deklarowania atrybutu został również dostosowany do zwykłej składni XML. Definicję atrybutu wiążemy z określonym elementem poprzez zagnieżdżenie tagu: <xsd:attribute name=”nazwaAtrybutu” type=”xsd:integer” /> Poza predefiniowanymi typami (znaczny repertuar) istnieje możliwość deklarowania własnych typów. Ogólnie zawartość schematu może być następująca: deklaracja XML; element-korzeń schema; definicje typów; deklaracje atrybutów i elementów. 27
28
Schematy a przestrzenie nazwowe
W samej definicji schematu możliwe jest jej przypisanie do określonej przestrzeni nazwowej. Służy temu atrybut targetNamespace. Dysponujemy wówczas dwiema przestrzeniami nazwowymi: przestrzenią standardowych elementów XML Schema; przestrzenią docelową; Z kolei, tak jak w każdym dokumencie XML można określić domyślną przestrzeń nazwową dla występujących w definicji schematu tagów: xmlns=URI przestrzeni nazwowej. Możemy ją przydzielić dla przestrzeni docelowej lub dla przestrzeni XML Schema (dla skrócenia odwołań do elementów standardowych lub zadeklarowanych lokalnie). 28
29
Wymuszanie kwalifikowania elementów
Możemy określić, czy zdefiniowane lokalnie elementy i atrybuty będą musiały być prefiksowane symbolem odpowiedniej przestrzeni nazwowej w zgodnych dokumentach: Następujące atrybuty w tagu „schema” okeślają sposób działania globalnie: elementFormDefault=”qualified” -> dotyczy prefiksowania elementów; oraz attributeFormDefauld=”qualified” -> dotyczy prefiksowania atrybutów (domyślną wartością jest w obu wypadkach ”unqualified”). To globalne ustawienie można modifikować atrybutami określanymi dla poszczególnych elementów: form=”qualified” albo ”unqualified ”. 29
30
Deklaracja korzenia schematu
<schema xmlns=" xmlns:po=" targetNamespace=" elementFormDefault="qualified" attributeFormDefault="unqualified"> … </schema> Lokalnie zdefiniowane atrybuty nie będą prefiksowane, zaś lokalnie zdefiniowane elementy będą wymagały prefiksowania. 30
31
Odwoływanie się w dokumentach do schematów
Bez przestrzeni nazw (sposób częściej stosowany): <elementKorzen xmlns:xsi=” xsi:noNamespaceSchemaLocation= ”plikNaszegoSchematu.xsd”> <!-- może tu też wystąpić URL --> </elementKorzeń> Z przestrzenią nazw: <naszaNamespace:elementKorzen xmlns:naszaNamespace= ” xsi:schemaLocation=” plikNaszegoSchematu.xsd”> </naszaNamespace:elementKorzeń> 31
32
Typy w XML Schema Określają rodzaj zawartości elementów oraz atrybutów. Wyróżniono 3 zasadnicze rodzaje: Typ wbudowany (m.in. wspomniane już string i integer); Typ prosty, zdefiniowany w dokumencie za pomocą elementu xsd:simpleType; Typ złożony, zdefiniowany w dokumencie za pomocą elementu xsd:complexType. Nie może dotyczyć atrybutów. Kategorie wbudowanych typów danych: Liczbowe, Znakowe, Daty i czasu, Logiczne,binarne, XML (np. ID, IDREF). 32
Podobne prezentacje
