XML схеми Описание на структурата на документа – DSD

1. XML схемиОписание на структурата на документа – DSD

2. XML схеми • Езикът на XML схемите е: • По- изразителен от XML DTD • Изразяващ се посредством XML • Само описващ се • Използваем от различни приложения, използващи XML • Целенасочено използваем за Internet • Оптимизиран за “interoperability” • Достатъчно прост за да сеприлага при проектиране • Съгласуван с изискванията на W3C спецификациите

3. XML схеми • Схеми и езици • Схемата е дефиниция на синтаксиса на XML-базиран език (т.е. тя дефинира клас от XML документи). Езикът на схемите е формален език за изразяване на схемите. Проверка за валидност – изискванията на схемата

4. XML схеми • Валидираният документ се нарича “екземпляр” или документ приложение. • Схемите са подобни на граматиките на езиците за програмиране. • XML схемите позволяват: • Разработка на приложения за обмен на данни с Web. • Реализиране на код, който установява или избягва грешките. • Деклариране на силно типизирани структури данни (например 10 април 2006 и 10/04/2006 са елементи дата, но с различен формат). • Възможност за модулност при дефиниране на структури, които да се ползват многократно. • Изразяване със синтаксиса на XML.

5. Основни принципи на схемите • XML Schema се състои от две основни части, дефинирани в документите: • Типове данни или “атоми”, които се използват като основа за по-големи компоненти на схемата • Структури или “съединения”, които се конструират от типовете данни и описват структурата на елементите, атрибутите и валидизирането на един документен тип. • Има два типа форматиране: • Дефиниции – създават нови типове (прости и сложни) • Декларации – описват моделите на съдържанието на елементите и атрибутите в документните инстанции.

6. Основни принципи на схемите Типове данни • Едно от големите предимства на схемите пред DTD е богатото множество от типове данни. • Както в програмните езици съществуват: • Примитивни типове данни – не са дефинирани чрез други типове. • Производни типове данни – дефинирани са чрез съществуващи. • Вградени типове (примитивните са и вградени като W3C може да ги добавя чрез изменение на спецификацията на XML Schema). • Производните могат да бъдат: вградени, дефинирани от W3C и създадени от потребителя,

7. Основни принципи на схемите Примитивни типове данни • Те винаги са вградени и могат да се използват за стойности на елементи или атрибути, но не могат да съдържат дъщерни елементи или атрибути. • Вградени примитивни типове в XML Schema:string, boolean, float (32 бита), double (64 бита), decimal, timeDuration, recurringDuration (повтарящо се времетраене), binary, uriReference (URI индентификатор), ID, IDREF, ENTITY, NOTATION

8. Основни принципи на схемите Производни типове данни • Дефинира се чрез съществуващ тип (базов). • Могат да съдържат XML код, валиден за дефиницията на типа им. • Могат да имат атрибути, могат да съдържат елементи или да имат смесено съдържание. • Вградени производни типове: integer, date, time,… Дефиниция на прост тип – производен тип данни за цяло отрицателно чрез рестрикция <simpleType name=“negativeInteger” base=“xsi:integer”> <minInclusive value=“unbounded”/> <maxInclusive value=“-1”/> </simpleType>

9. Основни принципи на схемите Атомни и списъчни типове данни • Атомни – имат неделими стойности. Например: числа, низове. • Списъчни – имат стойност, която е крайна последователност от атомни стойности. Те винаги са производни типове, които трябва да се разграничават с интервал, табулация,.. Създаден от потребителя производен списъчен тип <simpleType name=‘sizes’ base=‘decimal’ derivedBy=‘list’/> <ShoeSizes type=‘sizes’>8 8.5 9 9.5 10</ ShoeSizes> Може да се използва в елемент на документ

10. Основни принципи на схемите • Типовете данни се състоят от: • Пространство от стойности (всеки тип има диапазон от стойности). • Лексикално пространство (множество от валидни низове, представящи стойности). • Фасети (свойства на пространството от стойности). • Фасети: • Основни: • Равенство (за две стойности А и В са в сила правилата: А=А; ако А=В, то В=А; Equa(A,B) е вярно, ако А=В). • Подредба (подреден е типа, ако между стойностите му съществува дефинирано отношение). Например: А=В, или А<В, или А>В • Граници (стойностите могат да имат само горни, само долни или и двете) • Мощност (броят на стойностите в пространството от стойности – крайно; изброимо безкрайни; неизброимо безкрайно) • Числови/нечислови

11. Основни принципи на схемите • Фасети: • Ограничителни: ограничават пространството от стойности на производен тип, което ограничава лексикалното пространство. • length, minLength, maxlength – отнасят се до броя на единиците за дължина на типа данни. • pattern – ограничение върху лексикалното пространство на типа данни, което индиректно ограничава пространството от стойности. • enumeration – изброяването ограничава пространството от стойности до специфично множество. • minExclusive, maxExclusive, minInclusive, maxInclusive – само за подреден тип данни (минималните са за долната граница, а максималните – за горната). • precision, scale – за всички типове данни от десетичен тип. • encoding – стойностите на фасета са: hex, base64 • duration, period – за времетраене на стойностите recurringDuration и за честотата им на повторение.

12. Основни принципи на схемите Ако се изисква определена версия Асоцииране на схеми с XML документи <xsd:schema xmlns:xsd=“http://www.w3.org/1999/XMLSchema” xmlns:xsi=“http://www.w3.org/1999/XMLSchema-instance” version=“1.42.57”> . . . </xsd:schema> Първите 2 атрибута са за 2-те W3C схеми <schemaxmlns=“http://www.w3.org/1999/XMLSchema” . . . </schema> Правим пространството от имена наше (по подразбиране) – без xsd

13. XML схеми Един пример Пример за създаване на XML – базиран език на бизнес карти. Примерен документjohn_doe.xml: • За описване на синтаксиса на нашия нов език, създаваме схематаbusiness_card.xsd: <card xmlns="http://businesscard.org"> <name>John Doe</name> <title>CEO, Widget Inc.</title> <email>john.doe@widget.com</email> <phone>(202) 456-1414</phone> <logo url="widget.gif"/> </card>

14. XML схеми <schema xmlns="http://www.w3.org/2001/XMLSchema"xmlns:b="http://businesscard.org" targetNamespace="http://businesscard.org"> <element name="card" type="b:card_type"/> <element name="name" type="string"/> <element name="title" type="string"/> <element name="email" type="string"/> <element name="phone" type="string"/> <element name="logo" type="b:logo_type"/> <complexType name="card_type"> <sequence> <element ref="b:name"/> <element ref="b:title"/> <element ref="b:email"/> <element ref="b:phone" minOccurs="0"/> <element ref="b:logo" minOccurs="0"/> </sequence> </complexType> <complexType name="logo_type"> <attribute name="url" type="anyURI"/> </complexType> </schema>

15. XML схеми • Езикът на XML схемата се разпознава по областта на имената (namespace)http://www.w3.org/2001/XMLSchema. • Документ може да включва схемата посредством разположението на схемата (schemaLocation) (или noNamespaceSchemaLocation) атрибут: • С включването на горния текст, авторът потвърждава, че документът се предвижда да бъде валиден съобразно съответната схема. <card xmlns="http://businesscard.org" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://businesscard.org business_card.xsd"> ... </card>

16. Основни положения за XML схеми • Глобална декларация наелемент - свързва името на елемента с типа (type). • Дефиниция накомплексен тип –дефинира изискванията за атрибути, под-елементи и символни данни в елементите от този тип. - Декларации на атрибут – описва кои са атрибутите, които могат или трябва да се показват. - Указатели за елементи – описва кои са елементите, които могат или трябва да се показват и в какъв ред. • Дефиниция напрост тип – дефинира множество от символни низове, които да се използват като атрибутни стойности или символни данни. • (Два типа или два елемента не могат да се дефинират с едно и също име, но декларация на елемент и дефиниция на тип могат да използват едно и също име.)

17. Основни положения за XML схеми • Един елемент на XML документе валиден (valid) според зададената схема ако са удовлетворени правилата за свързване на типа елемент. • Ако всички елементи са валидни, то целият документ е валиден (valid). • Противно на DTD, не се изисква специфичен коренен елемент.

18. Дефиниции на типове данни • Прости типове данни – за създаване на производни типове • Сложни (комплексни) типове данни – за описване на модели на съдържание Дефиниции на прости типове данни • Дефиницията е множество от ограничения върху пространството от стойности и лексикалното пространство на типа данни. • Ограниченията са или ограничение (рестрикция) на базовия тип или указване на списъчен тип, ограничен от друга дефиниция на прост тип.

19. Дефиниции на типове данни Дефиниции на прости типове данни • Дефиницията ползва елемент <simpleType> с атрибути: name (името на типа); base (незадължителен за името на базовия тип); abstract (незадължителен - при стойност true този тип не може да е дефиниция на тип в декларация на елемент и не може да е атрибут в xsi:type); derivedBy (list | restriction) - незадължителен и по подразбиране е restriction.

20. XML схемиДефиниции на прости типове Примерна дефиниция на производен прост тип: <simpleType name="may_date"> <restriction base="date"> <pattern value="\d{4}-05-\d{2}"/> </restriction> </simpleType>

21. Дефиниции на типове данни Дефиниции на сложни (комплексни) типове данни • Дефиницията е множество от декларации на атрибути и тип на съдържанието (описва модела на съдържание), които съответно се отнасят до атрибутите и наследниците на този тип елемент. • Дефиницията ползва елемент <complexType>, неговите атрибути и ограничителни фасети. • Имената на атрибути, а също и примитивния тип данни или изброени стойности на атрибутите са от следните 3 групи: • name, base, abstract, derivedBy (тук е задължителен) • content – (elementOnly | empty | mixed | textOnly) • Атрибути за контрол на ОО възможности за наследяване на дефиниции на типове: block - “” или (#all | (extension | restiction))– за валидизиране на част от документ; final – “”или (#all | (extension | restiction)) – указва дали сложният тип може да се използва като базов тип на друг тип данни.

22. Дефиниции на типове данни Дефиниции на сложни (комплексни) типове данни • Има разлика между дефиниция на типа данни (чрез декларацията <complexType> ) и декларациите, описващи съдържанието на елемента (елементи наследници и атрибути). Първото описва тип данни, а второто – описва структурата на документния тип за валидизиране.

23. XML схемиДефиниция на комплексни типове • Комплексният тип (complexType) може да съдържа: • Декларации на атрибути • <attribute name="..." type=".." use=".."/>къдетоtypeсе отнася за дефиниция на прост тип иuseе или optional (незадължителен атрибут), required, илиprohibited (не може да присъства атрибут за родителския елемент) • <anyAttribute ... /> • Един от следните видове модели за съдържание: • emptycontent (по подразбиране) • simple content: <simpleContent> ... </simpleContent> (само за символни данни) • regexp content (определена комбинацияот)

24. XML схемиДефиниция на комплексни типове • <sequence> ... </sequence> • <choice> ... </choice> • <all> ... </all> • Съдържащи елементни референции от вида: • <element ref="..." minOccurs=".." maxOccurs=".."/>къдетоrefсе отнася към дефиниция на елемент, аminOccursиmaxOccursограничават броят за срещане (по подразбиране: 1) • <any .../> • (акоcomplexTypeима атрибутmixed="true", разрешени са произволни символни данни)

25. XML схемиКонструиране на комплексни типове Пример за деклариране на елементен тип <PersonName> <compexType name=“Text” content=“textOnly” base=“string” derivedBy=“restriction”/> <complexType content=“element”> <choice> <element name=“SingleName” type=“Text” minOccurs=“1” maxOccurs=“1”/> <sequence> <element name=“FirstName” type=“Text” minOccurs=“1” maxOccurs=“1”/> <element name=“MiddleName” type=“Text” minOccurs=“0” maxOccurs=“unbounded”/> <element name=“LastName” type=“Text” minOccurs=“1” maxOccurs=“1”/> </sequence> </choice> </complexType content=“element”>

26. XML схемиКонструиране на комплексни типове • Групови дефиниции • групи от атрибути – групи от атрибутни декларации могат • да се дефинират с: • <attributeGroup name="..."> ... </...> • и да се използват с: • <attributeGroup use="..."/>. • групи от елементи – подобно на групи от описанието на regexpмодел на съдържаниемогат да бъдат дефинирани и използвани с group construct • anyTypeе вграден тип, който позволява всичко. • ВcomplexTypeмоделът на съдържанието трябва да се появят преди всички атрибутни декларации.

27. XML схемиЛокални дефиниции Вместо писането на елементните декларации и дефинициите на тип глобално, те могат да бъдат включени локално(inlined). Пример: <element name="card" type="b:card_type"/> <element name="name" type="string"/> <complexType name="card_type"> <sequence> <element ref="b:name"/> <element ref="b:title"/> <element ref="b:email" maxOccurs="unbounded"/> <element ref="b:phone" minOccurs="0"/> <element ref="b:background" minOccurs="0"/> </sequence> </complexType>

28. XML схемиЛокални дефиниции Или написано по друг начин(където complex type card_type иописанието наname са inlined <element name="card"> <complexType> <sequence> <element name="name" type="string"/> <element ref="b:title"/> <element ref="b:email" maxOccurs="unbounded"/> <element ref="b:phone" minOccurs="0"/> <element ref="b:background" minOccurs="0"/> </sequence> </complexType> </element>

29. XML схемиПроизводни типове Производни чрез разширение– създава типcarот типаvehicleчрезразширение с 3 или 4 под - елемента wheel (колела).(Компонентите от базовия тип се наследяват като подразбираща се последователност). <complexType name="car"> <complexContent> <extension base="n:vehicle"> <sequence> <element name="wheel" minOccurs="3" maxOccurs="4"/> </sequence> </extension> </complexContent> </complexType>

30. XML схемиПроизводни типове Производни чрез ограничение–създаватип small_carот типаcarчрез ограничаване до 3 под елемента wheel.(Всички компоненти на базовия тип трябва да се повторят така, както е показано с "...".) <complexType name="small_car"> <complexContent> <restriction base="n:car"> <sequence> ... <element name="wheel" maxOccurs="3"/> </sequence> </restriction> </complexContent> </complexType>

31. XML схемиПроизводни типове Ако е деклариран елемент myVehicle, то той е валиден, ако е от типа vehicle. <element name="myVehicle" type="n:vehicle"/> Тъй катоcarе производен на vehicle, тоmyVehicleелементите са също валидни ако са от типа car. При условие, че се добавиxsi:type="n:car"към елементите (къдетоxsiсе отнасязаhttp://www.w3.org/2001/XMLSchema-instance) в документа екземпляр.

32. XML схемиПроизводни типове • Заместващи групи – това е алтернатива на производните типове: • Ако се декларира елемент: <element name="myCar" type="n:car" substitutionGroup="n:vehicle"/> То тогава може да се използва myCarелементи тогава, когато елементиmyVehicleса необходими (без използването наxsi:type). Това е независимо от разширение/ограничение наследяването! car не трябва да се декларира като под - тип наvehicle.

33. XML схемиАнотации Към схемите може да се добави анотация – документация, която е читаема от човек или машина, както и всяка друга информация. <xsd:element name="author"> <xsd:annotation> <xsd:documentation xmlns:xhtml="http://www.w3.org/1999/xhtml"> the author of the recipe, see <xhtml:a href="authors.xml">this list</xhtml:a> of authors </xsd:documentation> <xsd:appinfo xmlns:fp="http://foodprocessor.org"> <fp:process type="117"/> </xsd:appinfo> </xsd:annotation> ... </xsd:element>

34. XML схемиВключване на схеми и ре-дефиниране • Съществуват три механизъма: • <include schemaLocation="..."/> - схемата има същата област на данни • <import namespace="..." schemaLocation="..."/> - схемата има различна област на данни • <redefine schemaLocation="..."> ... </redefine> - схемата има същата област на данни; разрешени са редефиниции

35. XML схемиВключване на схеми и ре-дефиниране Пример: <schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:b="http://businesscard.org" targetNamespace="http://businesscard.org"> <import namespace="http://www.w3.org/1999/xhtml" schemaLocation="xhtml.xsd"/> <redefine schemaLocation="phone.xsd"> <element name="phone"> ... </element> </redefine> ... </schema> Включва се схема заXHTMLзаедно сphone.xsd (предполага се, че съдържа описание на телефонни номера) и се ре-дефинира описанието наphone.

36. XML схемиОбласти на данни Придефиниране на нов XML-базиран език, обикновено му присвояваме област на данни. • XML Схемата: • използва тази област – за различаване на инструкциите на схемата от езика, който се описва • подържа присвояването на областта – посредством свързване наtarget namespaceкъм описвания език <schema xmlns="http://www.w3.org/2001/XMLSchema"xmlns:b="http://businesscard.org"targetNamespace="http://businesscard.org"> <element name="card" type="b:card_type"/> ... <complexType name="card_type"> <sequence> <element ref="b:name"/> ... </sequence> </complexType> ... </schema>

37. XML схемиОбласти на данни • Областта по подразбиране(default)е тази на XML схема (същата, която считаcomplexTypeза елемент на XML схемата) • Областтаtargetе тази на“business card” • Префиксътbсъщо означава областта на “business card” (такава, че е възможно отнасяне къмконструкциите на target езика, вътре от самата схема).

38. XML схемиАтрибути и елементи по подразбиране • Страничен ефект от валидирането – това е включването на подразбиращи се (default) стойности • Всеки атрибут и елемент може да съдържаdefault="..."атрибут. • attribute defaults:те се включват преди валидирането, ако атрибутът отсъства (в елементи от тип съдържащ декларацията) • element defaults:включват се като character dataв празни (empty) елементи

39. XML схемиАтрибути и елементи по подразбиране В примерната схема, която съдържа: Процесорът на схемата ще валидира и трансформира: в: <element name="widget" default="no content explicitly provided"> <complexType mixed="true"> <attribute name="size" default="big"/> </complexType> </element> <widget/> <widget size="big">no content explicitly provided</widget>

40. XML схемиПълен пример за колекции рецепта • XML версията за колекция рецепти съдържа: • Всяка рецепта съдържа компоненти(ingredients), стъпки за приготовление(preparation), възможни са коментари(comments)и спецификации за хранителното съдържание (nutrition) като калории и др. • Компонентата може да бъдепроста (simple)илисъставна (composite) • Простата компонента има име(name), количество(amount) (възможно е да е неопределено) и мерни единици(unit) (освен ако количеството е без размер) • Съставната компонента представлява рекурсивна рецепта

41. XML схемиПълен пример за колекции рецепта XML версията за колекция рецепти(съкратена) е: <?xml version="1.0" encoding="UTF-8"?> <collection> <description> Some recipes used for the XML tutorial. </description> <recipe> <title>Beef Parmesan with Garlic Angel Hair Pasta</title> <ingredient name="beef cube steak" amount="1.5" unit="pound"/> ... <preparation> <step> Preheat oven to 350 degrees F (175 degrees C). </step> ... </preparation> <comment> Make the meat ahead of time, and refrigerate . . . </comment> <nutrition calories="1167" fat="23" protein="32"/> </recipe> ... </collection>

42. XML схемиПълен пример за колекции рецепта <schema xmlns="http://www.w3.org/2001/XMLSchema" 1/6 xmlns:r="http://recipes.org" targetNamespace="http://recipes.org" elementFormDefault="qualified"> <element name="collection"> <complexType> <sequence> <element name="description" type="r:anycontent"/> <element ref="r:recipe" minOccurs="0" maxOccurs="unbounded"/> </sequence> </complexType> </element>

43. XML схеми <complexType name="anycontent" mixed="true"> 2/6 <sequence> <any minOccurs="0" maxOccurs="unbounded" processContents="skip" namespace="##other"/> </sequence> </complexType>

44. XML схеми <element name="recipe"> 3/6 <complexType> <sequence> <element name="title" type="string"/> <element ref="r:ingredient" minOccurs="0" maxOccurs="unbounded"/> <element ref="r:preparation"/> <element name="comment" minOccurs="0" type="string"/> <element name="nutrition"> <complexType> <attribute name="protein" type="r:nonNegativeDecimal" use="required"/> <attribute name="carbohydrates" type="r:nonNegativeDecimal“ use="required"/> <attribute name="fat" type="r:nonNegativeDecimal" use="required"/> <attribute name="calories" type="r:nonNegativeDecimal“use="required"/> <attribute name="alcohol" type="r:nonNegativeDecimal" use="optional"/> </complexType> </element> </sequence> </complexType> </element>

45. XML схеми <element name="preparation"> 4/6 <complexType> <sequence> <element name="step" type="string" minOccurs="0" maxOccurs="unbounded"/> </sequence> </complexType> </element>

46. XML схеми <element name="ingredient"> 5/6 <complexType> <sequence> <element ref="r:ingredient" minOccurs="0" maxOccurs="unbounded"/> <element ref="r:preparation" minOccurs="0"/> </sequence> <attribute name="name" use="required"/> <attribute name="amount" use="optional"> <simpleType> <union> <simpleType> <restriction base="string"> <enumeration value="*"/> </restriction> </simpleType> <simpleType> <restriction base="r:nonNegativeDecimal"/> </simpleType> </union> </simpleType> </attribute> <attribute name="unit" use="optional"/> </complexType> </element>

47. XML схеми <simpleType name="nonNegativeDecimal"> 6/6 <restriction base="decimal"> <minInclusive value="0"/> </restriction> </simpleType> </schema> • Забележки: • Необходимо е установяване наelementFormDefault="qualified"за да се използва семантиката на стандартната Област на данни. • ДефинициитеnonNegativeDecimalиanycontentне са възможни при DTD. • Използвани са локални и глобални дефиниции. • Както и при DTD не може да се изрази, че: • unitтрябва да бъде използвано само при наличието наamount • Елементcommentможе да се появи навсякъде • Вложени елементingredient са разрешени само при отсъствието наamount

48. XML схеми При вмъкване в коренния елемент на: <collection xmlns=http://recipes.org xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://recipes.org recipes.xsd"> ... </collection> в колекцията на рецептаrecipes.xml, се декларира, че документът се счита за валиден според recipes.xsd.

49. XML схемиПроблеми • Основен проблем – голямата сложност • Практически ограничения на изрaзяването: • Не се изискваroot element (ето защо е необходима допълнителна • информация за валидиране дори на прости документи) • При описанието наmixed content, символните данни не могат да • се ограничат по никакъв начин • Декларациите на атрибути и съдържаниене могат да зависят от • атрибутите и елементите (това е и основен проблем на DTD). • defaultsне могат да се специфицират отделно от декларациите • (това прави трудно организирането на фамилии от схеми, които се • различават само по стойноститеdefault) • defaultsна елементите могат да бъдат само символни данни

50. XML схемиПроблеми • Основен източник на сложност: • Понятието "type" добавя допълнителен елемент на сложност: • - в документите екземпляри има елементи, които имат имена • - всхемите елементите се описват чрез "element definitions", • които свързват "element names" с "type names", • - дефинициите за тип (type) свързват "type names" с • описанията на елементи "element descriptions“, които описват • елементите в документите екземпляри • xsi:typeатрибутите се изискват в документите екземпляри, когатопроизводните типове се използват вместо базовите типове • Заместващите групи и локалните декларации (които не са с уникални имена) усложняват описанието на елемента.