Web-програмування та web-дизайн icon

Web-програмування та web-дизайн




НазваWeb-програмування та web-дизайн
Сторінка3/8
Дата15.05.2013
Розмір0.94 Mb.
ТипНавчальний посібник
1   2   3   4   5   6   7   8

Зауваження. Відзначимо, що в моделях елементів змішаного типу вміст може перелічувуватися тільки через знак «|» і повинен бути визначений або як нуль, або як множина (*). Роздільник «,» використовувати не можна.


^ ВИЗНАЧЕННЯ АТРИБУТІВ МАРКОВАНОГО ТИПУ


При використанні атрибутів маркованого типу можна накладати обмеження на значення атрибутів. Наприклад, можна дозволяти атрибутам брати тільки одне з двох заданих значень.

Розглядають 4 різних типи маркованих атрибутів:


ID – унікальним чином ідентифікує об'єкт;

IDREF – вказує на елементи, що містять атрибути ID;

ENTITIES – посилання на зовнішній елемент;

NMTOKEN – містить букви, цифри, крапки, знаки підкреслення, переноси і двокрапки, але не пропуски.


^ ВИКОРИСТАННЯ АТРИБУТІВ ТИПІВ ID І IDREF


Наприклад, в житті часто виникає ситуація, коли людина протягом дня робить позначки в щоденнику. Кожному повідомленню присвоюється унікальний ідентифікатор number. Також протягом дня виникають які-небудь коментарі, які можна записувати, а можна і не записувати. Якщо виникає необхідність записати коментар , його необхідно пов'язати з відповідною позначкою.








.


DTD-схема для даного документа виглядатиме так:


1:

2:

3:

4:

5:

6: day CDATA #REQUIRED

7: month CDATA #REQUIRED

8: year CDATA #FIXED "2009">

9:

10:

11:

12: hh CDATA #REQUIRED

13: mm CDATA #REQUIRED

14: ss CDATA #IMPLIED>

15:

16:

17:

18: number ID #REQUIRED

19: from CDATA #REQUIRED>

20:

21:

22:

23: txt IDREF #REQUIRED>

24:

25: ]>

26:

27:

28:

29:
.


Отже, запис в рядку 3:


говорить про те, що елемент note повинен містити елементи date*, time+, text+, comment+, які ідуть у порядку їх опису. Причому date може використовуватися скільки завгодно разів (*) або не використовуватися взагалі, елементи time, text, comment – повинні використовуватися мінімум один раз. Знак (*) у кінці специфікації елемента говорить про те, що група елементів може повторюватися скільки завгодно разів.

У рядках 5-8, 11-14, 17-19, 22 описуються атрибути елементів date, time, text, comment відповідно.

У рядку 18 вказується, що необхідний атрибут number має тип ID. Це означає, що атрибут number має бути унікальним, тобто не використовуватися тільки один раз.

У рядку 37: відсутній атрибут ss елемента time. Це пов'язано з тим, що ss був оголошений як атрибут типу IMPLIED.

Абсолютно по-іншому буде виглядати XML-документ, якщо специфікація в рядку 3 виглядатиме таким чином:





day CDATA #REQUIRED

month CDATA #REQUIRED

year CDATA #FIXED "2009">


hh CDATA #REQUIRED

mm CDATA #REQUIRED

ss CDATA #IMPLIED>


number ID #REQUIRED

from CDATA #REQUIRED>


txt IDREF #REQUIRED>

]>





.


А якщо вказати в рядку 3 специфікацію елемента note


,


то для правильності документа, рядки слід було б розмістити так:





day CDATA #REQUIRED

month CDATA #REQUIRED

year CDATA #FIXED "2009">


hh CDATA #REQUIRED

mm CDATA #REQUIRED ss CDATA #IMPLIED>


number ID #REQUIRED

from CDATA #REQUIRED>


txt IDREF #REQUIRED>

]>





.


Проте, розглянутий в прикладі xml-код, суперечить структурі документа, оскільки порушений порядок проходження елементів. Це обумовлено тим, що кожне повідомлення має свій час виникнення і саме це необхідно вказати розробникові. Помилку можна було б виправити шляхом введення в елементі time атрибута txt.

Тепер всі елементи йдуть один за одним в тому порядку, який вказаний у специфікації елемента note.


1:

2:

3:

4:

5:

6: day CDATA #REQUIRED

7: month CDATA #REQUIRED

8: year CDATA #FIXED "2009">

9:

10:

11:

12: txt IDREF #REQUIRED

13: hh CDATA #REQUIRED

14: mm CDATA #REQUIRED

15: ss CDATA #IMPLIED>

16:

17:

18:

19: number ID #REQUIRED

20: from CDATA #REQUIRED>

21:

22:

23:

24: txt IDREF #REQUIRED>

25:

26: ]>

27:

28:

29:

30:

31: Завтра відбудеться лекція з Web-дизану о 13.25

32:


33:

34: Терміново здати звіт

35:


36:

37:
.


^ ВИКОРИСТАННЯ ЕЛЕМЕНТІВ ENTITY В СХЕМАХ DTD


Елементи ENTITY – визначають елементи, що підставляються, тобто ті елементи, вміст яких обробник може замінювати наперед обумовленими даними. Інколи в XML такі елементи називають посиланнями.

Наприклад, в HTML елементами, що підставляються, були елементи, що задаються спец-символами, наприклад, кутові дужки < > ( < і >).

Оголошення посилань або елементів, що підставляються, здійснюється в схемі DTD.

На наявність елемента, що підставляється обробникові вказують спеціальні знаки & і ;. Вказані на початку і вкінці знаки обмежують рядок, який відповідає посиланню.

Приклад. Підстановка елементів XML з використанням визначень типів документів DTD.


1:

2:

3:

4:

5:

6:

7: txt IDREF #REQUIRED

8: hh CDATA #REQUIRED

9: mm CDATA #REQUIRED

10: ss CDATA #IMPLIED>

11:

12:

13:

14: from CDATA #REQUIRED>

15:

16:

17:

18:

19: ]>

20:

21:



На рисунку 8 подані результати обробки XML-коду браузером. При виявленні в рядках елемента, що підставляється &date; обробник замінює його рядком “2  жовтня 2009”.





Рисунок 8– Приклад використання елемента ENTITY


Пізніше ми детальніше познайомимося з елементами, що підставляються і способами їх застосування.


^ ВИКОРИСТАННЯ В СХЕМАХ DTD АТРИБУТІВ ПЕРЕЛІЧЕНОГО ТИПУ


Атрибути переліченого типу містять список допустимих значень, з яких можна вибрати будь-яке. Для того, щоб документ був правильним, атрибут може вибрати тільки те значення, яке вказане в списку.

Всі допустимі значення для описуваного в специфікації атрибута вказуються в дужках «(», «)» через вертикальний роздільник «|». Наприклад,


month CDATA #REQUIRED

year CDATA #FIXED "2009">


Таким чином, згідно специфікації атрибут day може приймати тільки значення, вказані в круглих дужках Sunday | Monday | Thursday, а за замовчанням завжди набувати значення Monday.





month CDATA #REQUIRED

year CDATA #FIXED "2009"

day (Sunday | Monday | Thursday ) "Monday">


txt IDREF #REQUIRED

hh CDATA #REQUIRED

mm CDATA #REQUIRED

ss CDATA #IMPLIED>


from CDATA #REQUIRED>


]>







Завтра лекція з Web-дизану о 13.25





Терміново здати звіт









Рисунок 9– Використання типів атрибутів з перерахуванням

У випадку, якщо в рядку


значення, яке набуває атрибут за замовчанням, не відповідатиме значенням, які перлічені в дужках, обробник негайно повідомить про помилку (рис. 10).




Рисунок 10 – Повідомлення про помилку


У разі потреби вказати, що даний атрибут є необов'язковим, використовують оголошення типу необов'язкового атрибута.


month CDATA #REQUIRED

year CDATA #FIXED "2009">


^ АНАЛІЗ ПРАВИЛЬНИХ ЕКЗЕМПЛЯРІВ


Оголошення зовнішніх схем DTD. Основна відмінність внутрішніх і зовнішніх схем полягає в тому, що зовнішні схеми DTD зберігаються у вигляді окремого файлу, а не як частина XML-документа.

До цих пір ми користувалися внутрішньою схемою DTD, яка задається таким чином:


]> .


Все, що зазначалося в квадратах дужках, було внутрішньою схемою DTD. Зовнішні схеми DTD зберігаються в окремих файлах з розширенням *.dtd .

Повна схема DTD для екземпляра XML складається з комбінації внутрішньої і зовнішньої схем (якщо вони існують).

Для того, щоб підключити зовнішню схему DTD до XML-документа, необхідно в рядку оголошення типу документа вказати слово SYSTEM або PUBLIC, після якого вказати URL адреса файлу, що містить схему DTD:

PUBLIC – використовується, якщо схема загальнодоступна і використовується багатьма користувачами (такі схеми зберігаються в спеціальній бібліотеці – репозиторії);

SYSTEM – використовується для вказівки власних схем.


Наприклад,


кореневий_елемент
SYSTEM “my_dtd.dtd”>.


^ Розділ 3 СХЕМИ XDR


Незважаючи на всі переваги схем DTD, з ними пов'язаний ряд проблем:

  1. Передусім вони не є екземплярами XML, робота з ними вимагає від розробника вивчення іншої мови програмування, що використовує інший синтаксис.

  2. Створювати, перевіряти і підтримувати на відповідність за допомогою редакторів і утиліт XML достатньо важко.

  3. Схеми DTD не надають контроль за типами даних, окрім текстових даних і типів документів, що ускладнює перевірку на відповідність стандартам у додатках, що використовують інші типи даних, наприклад, фінансові транзакції, обмін даними, наукові дані.

  4. Схеми DTD не є екземплярами XML, тому немає можливості розширити і перетворити такі схеми.

  5. Схеми DTD не забезпечують підтримку просторів імен XML, які дозволяють змішувати в документі елементи різних структур документів.

У зв'язку з переліченими недоліками стала необхідність використання інших схем, альтернативних DTD.

Схеми XDR визначають елементи, подані в екземплярі XML, а також будь-які атрибути, пов'язані з цими елементами, крім того в схемах XDR визначаються взаємозв'язки елементів XML-документа.

Дуже важливо усвідомити той факт, що XDR-схеми є екземплярами XML, тобто вони складаються з елементів і атрибутів XML, а отже, вони перевіряються на відповідність іншій схемі. Тому, створюючи XML-документ згідно розробленій XDR-схемі, програміст має ще справу і з третім документом, що містить середовище для XDR-файла.


^ РОЗРОБЛЕННЯ XDR –СХЕМ


Ми вже знаємо як підключати внутрішні і зовнішні схеми DTD, знаємо всі переваги таких схем і їх недоліки. Розберемося з тим, як працюють XDR-схеми.

Перш за все, відзначимо, що XDR-схеми – зовнішні. Зв'язок XML- файлу з його XDR-схемою прописується як атрибут кореневого елемента. Наприклад,


1:

2:

3: Завтра о 12.45 лекція з Web-дизайну

4:
.


Тут, в рядку 2 кореневий елемент note містить атрибут xmlns, який вказує, в якому файлі міститься відповідна XDR-схема.


^ ОГОЛОШЕННЯ ТИПУ ЕЛЕМЕНТА


Всі XDR-схеми описуються в окремому файлі, що має розширення *.xdr . Оскільки XDR-схема є XML-документом, то першим рядком є визначення документа

,


далі йде опис кореневого елемента. Кореневий елемент завжди виглядає таким чином:


1:
2: name=“ім’я_схеми”

3: xmlns=“urn:schemas-microsoft-com: xml-data”

4: xmlns:dt=“urn:schemas-microsoft-com: datatypes”>

5:

6:

7:

8:


У рядку 3 описується, на якому просторі імен базується опис елемента Schema. У рядку 4 оголошується простір імен для даних елемента Schema. Решта рядків (5-7) є рядками опису дочірніх елементів ElementType.

Опис елементів в XDR-схемах має такий синтаксис:



name= “idref”

сontent= “{empty|textOnly|eltOnly|mixed|}”

dt:type= “datatype”

model=“{open|closed}”

order=“{one|seq|many}” />


Тут кожен з атрибутів має значення, залежне від описуваного елемента

name – задає ім'я елемента

content– вказує на те, що містить описуваний елемент. Допустимими значеннями цього атрибута є:

  • empty – порожній елемент;

  • eltOnly – означає, що елемент може бути тільки контейнером для інших елементів;

  • textOnly – може містити тільки текст;

  • mixed – змішані дані (стандартне значення).

dt:type – оголошує тип даних елемента. Префікс дозволяє вказати простір імен для URI адрес.

model – дозволяє (open) або забороняє (closed) використовувати елементи, не визначені в схемі XDR.

order – оголошує порядок проходження дочірніх елементів екземпляра XML

  • one – припускає наявність одного елемента;

  • seq – указує елементи в строгому порядку;

  • many – припускає наявність будь-якої кількості елементів.


Наприклад, розглянемо схему schema_5.xdr, розроблену для XML-документа example_5.xml.


XDR-схема для example_5.xml буде такою:

1:

2:
3: name= “example_5”

4: xmlns=“urn:shemas-microsoft-com: xml-data”

5: xmlns:dt=“urn:shemas-microsoft-com: datatypes”>

6:

7:


У даній схемі дескриптор <Schema>, що відкривається, містить три атрибути. Атрибуту name (рядок 3) привласнено ім'я документа, для якого призначається схема, що розробляється.

У рядку 4 визначається стандартний простір імен для схеми XDR.

У рядку 5 визначається простір імен для типів даних, оголошених у схемі.

Рядок 6 детальніше описує елемент: ім'я, заборона використання неописаних в схемі елементів, вміст – лише текст, тип даних може бути тільки строковий.


^ ОГОЛОШЕННЯ ElementType ВКЛАДЕНИХ ЕЛЕМЕНТІВ


Точно так, як і в схемах DTD, XDR-схеми можуть описувати вкладені елементи. Опис вкладених елементів відбувається за правилом.


< ElementType name= ‘.’ >







Наприклад, для XML-документа example_6.xml:






Завтра о 12.45 лекція з Web-дизайну



,


де елемент має дочірній елемент text, XDR-схема виглядатиме так:


1:

2:
3: name= ‘example_6’

4: xmlns= ‘urn: shemas-microsoft-com: xml – data’

5: xmlns:dt=‘urn: shemas-microsoft-com: datatypes’>

6:

7:

8:


9:

10: .


Необхідно звернути увагу на те, що елемент text у схемі згаданий двічі. Перший раз описаний у рядку 7, як дочірній елемент елемента note, другий, – повністю визначається в рядку 9.

Як дочірні елементи для елемента ElementType можуть бути такі елементи:

Element – оголошує дочірній елемент

Description – забезпечує опис ElementType елемента

Datatype – визначає тип даних ElementType елемента

Group – визначає порядок проходження елемента

Attribute Type – визначає атрибут

Attribute – визначає відомості про дочірній елемент Attribute Type.


У разі розроблення XDR-схеми для елемента, що містить декілька пустих елементів, використовують наступний підхід.

Схема складена для прикладу example_7.xml:






.


XDR-схема example_7.xdr для XML-файлу example_7.xml.


1:

2:
3: name= ‘example_7’

4: xmlns= ‘urn: shemas-microsoft-com: xml – data’

5: xmlns:dt= ‘urn:shemas-microsoft-com: datatypes’>

6:

7:

8:

9:

10:


11:

12:

13:

14:


Внесення пустих дочірніх елементів в якості атрибутів елементів більш високого рівня, вважається прикладом гарного програмування .

Так, у попередньому прикладі порожніми елементами були time і data. Перенесемо їх у XML-документ як атрибути елемента note.

example_8.xml

1:

2:
3: time= ’12:54:13’

4: date= ’17-10-2009’>

5:

6: Завтра о 12.45 лекція з Web-дизайну

7:


8:


З появою атрибутів у елементі виникає необхідність використання в XDR-схемі елемента AttributeType.


^ ЕЛЕМЕНТ AttributeType


Синтаксис визначення елемента AttributeType має вигляд:



default=‘default-value’

dt:type=‘primitiv-type’

dt:values=‘enumerated-values’

name=‘idref’

required=‘{yes|no}’>.


Тут

default – значення атрибута за замовчанням. Наприклад, якщо атрибут відноситься до переліченого типу, значення за замовчанням повинне вказуватися у списку;

dt:type – тип даних для атрибута певного типу: entity, entities, enumeration, id, idref, idrefs, nmtoken, nmtokens, notation, string. При обраному типі enumeration необхідно вказувати і атрибут dt:values;

dt:values – містить всі допустимі значення, якщо dt:type=‘enumeration’;

name – ім'я типу атрибута. Цей атрибут обов'язковий;

required – указує на необов'язкову наявність атрибута в описі елемента.

У даному прикладі атрибут відноситься до елемента note. Тому ElementType для елемента note міститиме і елементи, і AttributeType, і Attribute.

Розглянемо синтаксис елемента Attribute.



default=‘default-value’

type=‘attribute-type’

required= ‘{yes|no}’>.


Тут

default – значення атрибута за замовчанням. Має перевагу перед будь-яким значенням за замовчанням, вказаним в елементі AttributeType;

type – ім'я елемента AttributeType, яке визначене в даній схемі (або в іншій, вказане за допомогою відповідного простору імен). Вказане значення повинне відповідати значенню атрибута name в AttributeType;

required – вказує на необов'язкову наявність атрибута в описі елемента. Необов'язковий, якщо необхідний атрибут присутній в AttributeType.

Таким чином, для прикладу example_8.xml XDR-схема буде мати такий вигляд:

1:

2:
3: name='example_8'

4: xmlns= 'urn:shemas-microsoft-com:xml-data'

5: xmlns:dt='urt:shemas-microsoft-com:datatype'>

6:

7:
8: dt:type='time'

9: name= 'time'

10: required='yes'/>

11:
12: type= 'time'

13: required='yes'/>

14:
15: dt:type='date'

16: name= 'date'

17: required= 'yes'/>

18:
19: type= 'date'

20: required= 'yes'/>

21:

22:


23:

24: .


Якщо в рядку

4: date= ’17-10-2009’

прикладу example_8.xml внести зміни

4: date= ’17 жовтня 2009’

валідатор при перевірці XML-документа повідомить про помилку «невідповідність типів даних».


^ ТИПИ ДАНИХ У XDR-СХЕМАХ


bin.base64


  • двійкові дані з використанням шифрування MIME;

bin.hex


  • визначає двійкові дані в шістнадцятиричному форматі;

boolean

  • 0 або 1;

char


  • символ (рядок, що складається з одного символу);

date


  • указує на дату без часу у форматі ISO-8601, наприклад, 2009-10-16. Проте правильність зазначення дати не перевіряється, тобто допустиме значення і дати 17-41-59;

dataTime


  • вказує дату (вказівка часу необов'язкова) в підмножині формату ISO-8601, наприклад, 2009-10-16 T09:57:12;

dataTime.tz


  • вказує дату (вказівка часу і часового поясу необов'язково) в підмножині формату ISO-8601. Наприклад, 2009-10-16 T09:57:12-02:00;

fixed.14.4


  • визначає десяткове число, що містить не більше 14 знаків зліва і не більше 4 цифр праворуч від десяткової крапки;

float


  • визначає дійсне число (без обмежень на кількість цифр), може містити знак дробу, а також показник ступеня, значення від 1.797693E+308 до 2.22507Е-308;

int

  • ціле число з необов'язковим знаком;

number


  • визначає число без обмеження цифр, може містити знак дробу і ступінь значення від 1.797693E+308 2.22507Е-308;

time


  • вказує час без дати і часового поясу в підмножині формату ISO – 8601, наприклад, 10:14:51;

time.tz


  • вказує час і часовий пояс, наприклад, 10:14:51+02:00;

i1


  • визначає ціле число, представлене одним байтом (1-128). Дробові знаки і знаки піднесення до ступеня не допускаються;

i2


  • визначає ціле число, представлене одним словом (1-32768);

i4


  • визначає ціле число, представлене чотирма байтами (1-1000 000 000);

i8


  • визначає ціле число, представлене вісьма байтами;

r4


  • дійсне число з точністю 7 цифр. Може містити знак, дробову частку необов'язковий знак ступеня;

r8

  • дійсне число з точністю 15 цифр;

ui1


  • ціле число без знаку, дробової частки або ступеня;

ui2


  • ціле число, що складається з 2 байтів, без знаку, дробової частки або ступеня;

ui4


  • ціле число, що складається з 4 байтів, без знаку, дробової частки або ступеня;

ui8


  • ціле число, що складається з 8 байтів, без знаку, дробової частки або ступеня;

uri


  • уніфікований індикатор ресурсу URI, наприклад, urn: schemas-microsoft-com:Office 9.0;

uuid


  • шістнадцятиричне число, розбите на октети, містить необов'язкові перенесення, які ігноруються, наприклад, 345FFD3A1-F501-FA33-12-AD3804-345FFD3A1.



^ ІНДИКАТОРИ ВХОДЖЕННЯ В XDR-СХЕМАХ


У XDR-схемах необхідно указувати скільки разів дочірній елемент може зустрічатися в батьківському елементі. Для цього в описі дочірнього елемента element використовують атрибути minOccur і maxOccur.

Повний синтаксис елемента такий:



type= ’тип_елемента’

minOccur = ’{0|1}’

maxOccur=’{1|*}’ />.


За замовчанням обидва атрибути і minOccur, і maxOccur набувають значення 1.

Для демонстрації роботи атрибутів minOccur і maxOccur елемента element внесемо до XML-документ example_8.xml зміни, повторивши використання елемента text кілька разів. Валідатор тут же відреагує на невідповідність XML-даних XDR-схеми, вказаній в рядку 2.


example_9.xml

1:

2:

3: time= ’12:54:13’

4: date= ’17-10-2009’>

5:

6:18.10.2009 у 12.45 лекція з Web-дизайну

7:


8:

9: 18.10.2009 о 13.25 практика з Web-дизайну

10:


11:

12:20.10.2009 знову о 12.45 лекція з Web-дизайну

13:


14:



Для того, щоб уникнути подібних помилок змінимо XDR-схему.


example_9.xdr


1:

2:
3: name='example_8'

4: xmlns='urn:shemas-microsoft-com:xml-data'

5:xmlns:dt='urt:shemas-microsoft-com: datatype'>

6:

7:
8: dt:type='time'

9: name='time'

10: required= 'yes'/>

11:
12: type='time'

13: required='yes'/>

14:
15: dt:type='date'

16: name='date'

17: required= 'yes'/>

18:
19: type= 'date'

20: required='yes'/>

21:

22:


23:

24:


^ ДОДАТКОВІ ОБМЕЖЕННЯ ТИПІВ ДАНИХ

У XDR-СХЕМАХ


Наприклад, інколи при обробці типу даних string, досить використовувати рядки визначеної довжини. Але сам тип припускає необмежену довжину, тому виникає необхідність штучно обмежити довжину даних. Така ж ситуація може виникнути і у випадку з іншими типами, такими як number, bin.hex, bin.base64.

Для таких випадків були введені додаткові атрибути елемента AttributeType, при цьому використовується такий синтаксис:



name=’idref’

dt:type=’string|number|bin.hex|bin.base64}

recuired=’{yes|no}’

dt:minLenght=’додатне ціле число’ dt:mаxLenght=додатнє ціле число’ />


^ ВИКОРИСТАННЯ ГРУП ВМІСТУ


В електронній комерції часто виникають ситуації, коли при перевірці яких-небудь даних може виникнути помилка, тому відкидається цілий документ. Але замість того, щоб відхилити цілу транзакцію, користувачеві пропонують змінити тільки той блок коду, який не пройшов верифікації.

Наприклад, необхідно отримувати відомості про те, що повідомлення було отримане повністю. Крім того, необхідно, щоб додаток перевіряв екземпляр XML так, щоб у ньому була потрібна наявність того або іншого повідомлення.

Нехай маємо XML-документ example_10.xml







time=’12:15:45’

date=’2009-10-18’

number=’n1’

from=’Проценко О.Б.’>

Завтра лекція з Web-дизайну о 13.25




time=’14:45:15’

date=’2009-10-18’

number="n2"

from="Керівник відділу"> Терміново здати звіт
.

Введемо після кожного елемента text новий елемент , у рамках цього елемента розглянемо дочірній порожній елемент або .

У результаті отримаємо example_10.xml







time=’12:15:45’

date=’2009-10-18’

number=’n1’

from=’Проценко О.Б.’>

Завтра лекція з Web-дизайну о 13.25






time=’14:45:15’

date=’2009-10-18’

number=’n2’

from=’Керівник відділу’>

Терміново здати звіт









.


Для перевірки цього документа створимо групу змісту в схемі XDR, що містить елементи і .


Групи змісту створюються завдяки елементу XDR-схеми , який є дочірнім у батьківському елементі ElementType.

Синтаксис елемента :







.


У даному випадку, фрагмент XDR-схеми буде мати такий вигляд:



order=’one’





.


Повна схема XDR виглядатиме так:


1:

2:
3: name= 'example_10'

4: xmlns= 'urn:shemas-microsoft-com:xml-data'

5: xmlns:dt='urt:shemas-microsoft-com: datatype'>

6:
7: name='note'

8: content='eltOnly'

9: model='close'

10: order=’many’>

11:
12: type=’text’

13: minOccure=’1’

14: maxOccure=’*’ / >

15:
16: type=’report’ / >

17:


18:
19: name=’incomplete’

20: model=’close’

21: content=’empty’/>

22:

23:
24: name=’complete’

25: model=’close’

26: content=’empty’/>

27:

28:
29: name=’text’

30: model=’close’

31: content=’textOnly’/>

32:

33:
34: dt:type= 'time'

35: name= 'time'

36: required= 'yes'/>

37:
38: type= 'time'

39: required= 'yes'/>

40:
41: dt:type= 'date'

42: name= 'date'

43: required= 'yes'/>

44:
45: type= 'date'

46: required= 'yes'/>

47:
48: name= 'date'

49: dt:type= 'string'

50 dt:maxLength=’15’

50: required= 'yes'/>

51:
52: type= 'from'

53: required= 'yes'/>

54:


55:

56:

57:

58:

59:


60:


61: .


^ Розділ 4 МОВА ВИЗНАЧЕННЯ СХЕМ XML ( XSD)

Основні риси мови визначення схем xml (xsd)

Мова XML Schema Definition Language, яку також називають XML Schema Language, багато в чому схожа на мову XDR, з якою ви познайомилися раніше. Схеми XSD здатні розв’язувати такі задачі:

  • Перелічення елементів у документі XML і перевірка наявності в документі тільки оголошених елементів.

  • Оголошення і визначення атрибутів, що модифікують елементи документа.

  • Визначення батьківсько-дочірніх стосунків між елементами.




  • Визначення станів і моделей вмісту для елементів і атрибутів.

  • Завдання типів даних.

  • Установка значень за замовчанням.

  • Можливість розширення.

  • Підтримка використання просторів імен.

Усі схеми, незалежно від використовуваних для їх створення словників і синтаксичних правил, призначені для задання певних обмежень на документи XML, а отже, для забезпечення відповідності останніх певним правилам. Мови опису схем, які базуються на синтаксисі XML, володіють певними перевагами перед DTD, оскільки допускають розширення використовуваних дескрипторів розмітки, а також перевірку документів і схем за допомогою стандартного синтаксичного аналізатора XML.

У схемах XSD дескриптори, що використовуються в документах XML, розділяються на дві категорії :

– складні типи. Елементи складних типів можуть містити інші елементи, а також володіють певними атрибутами, тобто мати змішаний вміст;

– прості типи.

Наприклад, до простого типу можна віднести дескриптор

Завтра о 12.45 лекція з Web-дизайну.

Фрагмент, наведений нижче, містить дескриптор note, який може вважатися за складний.


date= ’17-10-2009’>



Завтра о 12.45 лекція з Web-дизайну


.


Прості і складні типи елементів — це унікальні характеристики мови XSD.


^ ПРОСТОРИ ІМЕН


Будь-яка схема повинна використовувати стандартний простір імен для всіх екземплярів XSD. Цей простір імен ідентифікує набір елементів і атрибутів, які утворюють словник XSD.

Кореневим елементом у схемі XML є елемент Schema, який містить решту всіх елементів у документі схеми.

У рамках кореневого елемента схеми XSD створюється простір імен, використовуючи атрибут xmlns. Наприклад, наведений нижче дескриптор належить угоді про використання префікса "xsd" для зв'язку елементів з іменованою колекцією:


http://www.w3c.org/1999/XMLSchema’.


За загальною угодою префікс xsd використовується для зв'язку екземпляра XML-документа зі схемою. Проте і його використання має бути узгоджене з іменованою колекцією, тобто префікс має бути описаний шляхом використання атрибута xmlns


xmlns:xsi="http://www.w3.org/2000/10/

XMLSchema-instance".


Для зв'язку екземпляра документа XML із схемою найчастіше використовуються два атрибути:


xsi:schemaLocation

xsi:noNamespaceSchemaLocation.


Ці атрибути дозволяють пов'язувати документ із стандартом XML Schema консорціуму W3C^ . Такий зв’язок не обов'язковий, але дуже корисний, оскільки дозволяє синтаксичним аналізаторам швидше знаходити потрібну схему.

У випадку, якщо використовується локальний файл, використовують атрибут


xsi:noNamespaceSchemaLocation.


Наприклад,


xsi:noNamespaceSchemaLocation=

’ім’я _файлу.xds’


З іншого боку, простір імен може бути оголошений разом з ім'ям файлу, тоді ідентифікатор URI для простору імен і ідентифікатор URI для схеми розділяються пропусками, утворюючи значення одного атрибута, як показано нижче:


xsi:schemaLocation=http://example.org/ns/

books/ ім’я_файлу.xsd.


^ ПРОСТІ ЕЛЕМЕНТИ


Концепція іменованих типів

На відміну від DTD і XDR схем існує концепція іменованих типів. Наприклад, при створенні визначень існує можливість привласнювати цьому визначенню ім'я, щоб повторно використовувати його в екземплярі XSD.

Наприклад, розглянемо фрагмент, що містить два прості елементи


Листопад,14,2009

Відвідати лекцію, дуже важливий матеріал .


Як видно, типом вмісту обох елементів є рядки. Для повного визначення елементів згідно з XSD схемою необхідно вказати назву елемента і його тип




.


Як видно, обидва елементи містять опис type=’xsd:string’, що дублюється. Щоб уникнути такого, звертаються до концепції іменованих типів або іменованих обмежень. Іменовані обмеження задають так:

.


Наприклад, якщо в схему ввести| іменоване обмеження


.


Опис елементів виглядатиме так:




.


Таким чином, у нашому прикладі, елемент типу string посилається на елемент типу simpeType.

Розглянемо приклад, в якому наведемо XML-документ, що містить прості елементи і XSD-схему, для XML-документа.

  1. «голий» XML-документ



Відвідати лекцію, дуже важливий матеріал


  1. XSD-схема (example_11.xsd) для простого XML-документа




xmlns:xsd=’http://www.w3.org/2000/10/

XMLSchema’>






  1. Підключаємо схему до XML-документа (example_11.xml)




xmlns:xsi=’http://www.w3.org/2000/10/XMLSchema-instance’

xsi:noNamespaceSchemaLocation=’example_11.xsd’>

Відвідати лекцію, дуже важливий матеріал

.


^ ПРОСТІ ТИПИ ДАНИХ, ЩО ВИКОРИСТОВУЮТЬСЯ В СХЕМАХ XSD


У таблиці наведені типи даних, які відносяться і до типів даних, і до атрибутів.


^ Простий тип

Опис

string

Буквено-цифровий рядок

normalizedString

Рядок без пропусків

byte

1,126

unsignedByte

0,126

Integer

-126789, -1, 0, 1, 126789

Positivelnteger

1, 126789

Negativefnteger

-1267879, -1

nonNegativelnteger

0, 1, 126789

nonPositivelnteger

-1267879, -1, 0

Int

-1, 126789675

Unsignedlnt

0, 1267896754

Long

-1, 12678967543233

Продовження таблиці

unsignedLong

0, 12678967543233

float




double




Boolean

True, false, 1, 0

Time

13:20:00.000,

13:20:00.000-5:00

dateTime

1999-05-31T1313:20:00.000-5:00

date

1999-05-31

gMonth

--11--

gYear

2007

gYearMonth

2007-11

gDay

---14

gMonthDay

--11-14



^ ЕЛЕМЕНТИ СКЛАДНИХ ТИПІВ


Вміст елементів складного типу може бути різним. Він може включати текст, інші елементи, атрибути і т.д.

Наприклад.

1 Маємо XML-документ, який містить елемент складного типу:






Завтра о 12.45 лекція з Web-дизайну



.


2 Розробимо XSD-схему обмежень для даного документа

Опис елемента складного типу, що має елемент, відбувається в строго обумовленому порядку. А саме:







type=’простий_тип’>



.


Згідно з вимогами XSD-схема документа (example_12.xsd) виглядатиме так:





xmlns:xsd=’http://www.w3.org/2000/10/XMLSchema’>










(у даному випадку необов'язково указувати на послідовність дочірніх елементів)










.


XML-документ з підключеною схемою XSD:





xmlns:xsi=’http://www.w3c.org/2000/10/

XMLSchema’>

xsi:noNamespaceSchemaLocatin=’example_12.xsd’>



Відвідати лекцію, дуже важливий матеріал



.

^ ОБМЕЖЕННЯ ВХОДЖЕНЬ У СХЕМАХ XSD


XSD дозволяє визначити кількість входжень елемента з певною точністю: задати мінімальну і максимальну кількість входжень елемента за допомогою атрибутів minOccur і maxOccur елементу xsd:element відповідно.

Використання цих атрибутів може здатися схожим на їх використання в XDR-схемах, але це тільки на перший погляд.

У випадку мови XSD на можливі значення цих атрибутів накладаються певні обмеження. Це пов'язано з тим, що консорціум W3C визначив бажаний діапазон входжень. Це одна з найбільш відмінних характеристик XSD по відношенню до XDR, DTD і іншим мовам опису схем.

Якщо ніщо інше не вказано, то значення за замовчанням атрибутів minOccur і maxOccur дорівнюють "1". Атрибут maxOccur також може набувати значення "unbounded", що аналогічно значенню "*" в мовах DTD і XDR.


1:

2:
3: xmlns:xsi=’http://www.w3.org/2000/10/

XMLSchema-instance’

4: xsi:noNamespaceSchemaLocation=

’example_13.xsd’>

5:

6:

7: Раптово випав сніг

8: А завтра лекція з web-дизайну

9:


10:

11:

12: Забрати книгу

13: Знайти літературу

14: Підготуватися до семінару

15:


16: .


На документ передбачається накласти ряд обмежень:

  1. У документі допускаться не більше двох елементів notes.

  2. Входження елементів notes необов'язкові.

  3. Елемент number повинен передувати елементу text.

  4. Повинен існувати як мінімум один елемент text.


Для створення схеми XSD, що відображає всі ці обмеження, необхідно вказати:


  • кількість елементів;

  • порядок їх слідування;

  • обов'язкові і необов'язкові елементи.



Для того, щоб задати обмеження на кількість елементів, використовуйте атрибути minOccur і maxOccur відповідних елементів xsd:element. У XSD можна додати обмеження, що стосуються обов'язкової наявності елементів, використовуючи ті ж самі атрибути minOccur і maxOccur. Наприклад, якщо задати атрибут minOccur таким, що дорівнює 0 для певного елемента або взагалі виключити цей атрибут, щоб використовувати його значення за замовченням, цей елемент вважатиметься за обов'язковий. (Обов'язковим є як мінімум одне входження елемента.) Ви вже знаєте, що значення більше 1 для атрибута maxOccur позначається як "unbound".

Розглянемо можливий варіант схеми XSD, що відображає вищенаведені обмеження


1:

2:

3:

4:

5:

6:

7:

8:

9:


10:


11:


12:


13:

14:

15:

16:


17:


18:
.


Складна послідовність називається notesType тільки для зручності; ви можете називати її, як тільки захочете.


^ ОПИС АТРИБУТІВ


Оголошення атрибутів у схемах XSD дуже схоже на оголошення елементів, за винятком того, що атрибути оголошуються за допомогою оголошень attributes, а не element. Як вже наголошувалося раніше, оголошення атрибутів містяться у визначеннях складних типів у схемах.

Наприклад, example_14.xml


1:

2:
3: xmlns:xsi=’http://www.w3.org/2000/lO/

XMLSchema-instance’

4: xsi:noNamespaceSchemaLocation=

’example_14.xsd’>

5:

6: Потрібно здати ОДЗ. ТЕРМІНОВО!!!!

7:


8: .


Цьому документу в схемі XSD повинен відповідати складний тип. Схема XSD для перевірки документа наведена в лістингу 6.9. У цьому лістингу проілюстровано декілька додаткових засобів, які ми ще не розглядали.

Вказівка типів даних у схемах XSD складається з декількох етапів. Ви починаєте обмежувати типи елементів однією досить загальною категорією, після чого звужуєте цю категорію до певних типів. Такий підхід може здатися надлишковим, проте він корисний при роботі з великими схемами, що містять велику кількість типів даних.

Перший, найбільш загальний тип, вказується за допомогою елемента xsd: restriction з атрибутом base, що оголошує широку категорію. Зазвичай атрибут base=’xsd:string’. Дочірні елементи елементів xsd:restriction містять докладні визначення типів даних. Все це показано нижче.

Схема XSD з перевіркою атрибутів example_14.xsd





xmlns:xsd="http://www.w3.org/2000/10/XMLSchema">





//не містить атрибут name



//оголошуємо широку категорію (базу для типів //даних)


type="xsd:integer"

use="required"/>











//не містить атрибут name




type="textType"/>

//містить посилання на оголошення складного типу //з оголошенням атрибута







.


Підтримка типів даних мовами XSD і XDR значно відрізняє їх від DTD, який такою підтримкою не володіє зовсім. Консорціум W3C доклав всі можливі зусилля, щоб реалізувати в XSD підтримку найбільш широкого набору типів даних.


XSD розділяє всі типи даних на дві групи:

– базові (primitive);

– похідні (derived).


^ Базові типи даних — це такі типи даних, які не виражаються за допомогою інших типів даних.

Похідні типи даних — це такі типи даних, які виражаються за допомогою інших базових типів даних.

Розглянемо, наприклад, такий основний тип даних, як float, а також похідний тип даних integer. Тип даних float — це чітко визначена математична концепція, яку не можна виразити в термінах інших типів даних, тоді як integer — це різновид більш загального типу даних decimal.

Таким чином, тип даних integer похідний від типу даних decimal.


Розглянемо ще один приклад


1:

2:
3: xmlns:xsi= "http://www.w3.org/2000/10/

XMLSchema-instance"
4:xsi:noNamespaceSchemaLocation=

"message06.xsd">

5:

6: Коли я дочекаюся від Вас ОДЗ?!

7:


8: .


Опишемо всі атрибути:






.


Кожен елемент attribute в цьому прикладі оголошується за допомогою атрибутів name (відповідає імені елемента в документі XML), type (оголошення типу даних відповідно до описаних раніше обмежень) і use (визначення того, обов'язковий чи ні атрибут). Якщо ви оголошуєте атрибути як обов'язкові, вам необхідно вказати атрибут use="required" для кожного елемента xsd:attribute.


1:

2:

3:

4:

5:

6:
type="xsd:integer"

use="required"/>

7:
type="xsd:date"

use="required"/>

8:
type="xsd:string"

use="required"/>

9:

10:

11:
12:
13:

14:

15:

16:


17:


18:


19: .


^ ПЕРЕВІРКА ДОКУМЕНТІВ. ТРИ ПІДХОДИ: XDR, DTD, XSD


Отже, було розглянуто три пов'язаних підходи, що відрізняються. Вони забезпечують перевірку документів на відповідність синтаксичним правилами і стандартам, які визначаються спеціальними обмеженнями. Схеми DTD використовуються найдовше і підтримуються великою кількістю варіацій застосувань. Якщо необхідні строгі вказівки обмежень, то DTD найменш гнучкий з трьох мов опису схем, що були розглянуті, — саме те, що необхідне. Отже, в схемах DTD не використовується синтаксис документів XML, що є важливою перевагою над іншими мовами. Хоча використання синтаксису XML в схемі необов’язково приводить до поліпшення процесу перевірки, воно приводить до додаткової гнучкості, а також дозволяє перетворення в інші мови розмітки, чим не може похвалитися DTD. Схеми, що базуються на словниках XML, можуть містити складнішу і виразнішу розмітку, а також складні обмеження змісту.

Можливо, найбільш важливим поліпшенням, пов'язаним із схемами на базі XML, є можливість перевірки типів даних. Мови XSD і XDR підтримують достатньо широкий діапазон типів даних. XSD підтримує навіть більше типів даних, ніж XDR.


^ ОСНОВИ ВИКОРИСТАННЯ XSL-ТАБЛИЦЬ СТИЛІВ


Існують два основні кроки для відображення XML-документа при використанні XSL-таблиць стилів.

  1. Створення файлу XSL-таблиці стилів. XSL є додатком XML, тобто XSL-таблиця є коректно сформованим XML-документ, який відповідає правилам XSL. Подібно до будь-якого XML-документа, XSL-таблиця стилів містить простий текст, і ви можете створити її за допомогою будь-якого текстового редактора.

  2. ^ Пов'язування XSL-таблиці стилів з XML-документом. Ви можете пов'язати XSL-таблицю стилів з XML-документом, включивши у документ інструкцію з обробки xml-stylesheet, яка має таку узагальнену форму запису:





Тут XSLFilePath є включений у лапки URL, який вказує місцезнаходження файлу таблиці стилів. Ви можете використовувати повний URL, наприклад:



href="http:/www.my_domain.com/Inventory.xsl"?>


Частіше використовують неповний URL, який задає місцезнаходження XML-документа, що містить інструкцію з обробки xml-stylesheet, наприклад:

.


(Відносний URL зустрічається частіше, оскільки ви зазвичай зберігаєте файл таблиці стилів у тій самій папці, де зберігається XML-документ, або в одній із вкладених в неї папок.)

Довідка. Хоча можна зв'язати XSL-таблицю стилів з використанням повного URL, таблиця стилів при цьому повинна розміщуватися на тому ж домені, що і XML-документ, з яким він пов'язаний. Наприклад, якщо домен http://mspress.microsoft.com/ містить XML-документ, то і XSL-таблиця стилів повинна розміщуватися на тому ж домені.

Як правило, інструкція з обробки xml-stylesheet додається в пролог XML-документа за оголошенням XML.

Якщо ви пов'язали XSL-таблицю стилів із XML-документом, можна відкрити цей документ безпосередньо в браузері, який відображатиме XML-документ з використанням інструкцій з перетворення стилів, що містяться в таблиці. На відміну від каскадних таблиць стилів, якщо ви пов'язуєте з XML-документом більше, ніж одну XSL-таблицю стилів, браузер використовує першу таблицю і ігнорує всі останні. Якщо ви пов'яжете з XML-документом і CSS-таблицю, і XSL-таблицю стилів, браузер використає тільки XSL-таблицю стилів.
^

Використання одного шаблону XSL


На відміну від CSS, що містить правила, XSL-таблиця стилів включає один або декілька шаблонів, кожен з яких містить інформацію для відображення в певній гілці елементів в XML-документі. Існує можливість створити просту XSL-таблицю стилів, яка включає тільки один шаблон. Цей шаблон містить інформацію для відображення всього документа.

Далі поданий перший приклад XSL-таблиці стилів example_15.xsl. Ця таблиця стилів пов'язана з XML-документом:








1   2   3   4   5   6   7   8

Схожі:

Web-програмування та web-дизайн iconПрограма Основний синтаксис
...
Web-програмування та web-дизайн iconМетодичні вказівки до виконання курсової роботи з дисципліни «Web-програмування» для студентів напряму 030502 економічна кібернетика
Курсова робота самостійна робота студента, мета якої полягає в систематизації, закріпленні і поглибленні знань, одержаних при вивченні...
Web-програмування та web-дизайн iconЛекція №2. Стандарти Web Створення World Wide Web «Війни браузерів» Поява стандартів Web Формування W3c розвиток стандартів Web
У 1993 р у світі працювало 1700 Gopher-серверів. Але після того, як університет оголосив, що збирається вимагати ліцензійні відрахування...
Web-програмування та web-дизайн iconРазработка Web-сервиса на основе php и Mysql
На платформе Microsoft. Net или J2ee web-сервис представляет собой развитый сервер на основе wsdl (Web Service Definition Language),...
Web-програмування та web-дизайн iconТехническая документация web ирбис64 и web ирбис32
Команда чтения внутреннего двоичного объекта из библиографической записи – «интегрированный файл»(3) 12
Web-програмування та web-дизайн iconТехническая документация web ирбис64 и web ирбис32
Команда чтения внутреннего двоичного объекта из библиографической записи – «интегрированный файл»(3) 12
Web-програмування та web-дизайн iconТехническая документация web ирбис64 и web ирбис32
Команда чтения внутреннего двоичного объекта из библиографической записи – «интегрированный файл»(3) 12
Web-програмування та web-дизайн iconТехническая документация web ирбис64 и web ирбис32
Команда чтения внутреннего двоичного объекта из библиографической записи – «интегрированный файл»(3) 9
Web-програмування та web-дизайн iconТехническая документация web ирбис64 и web ирбис32
Команда чтения внутреннего двоичного объекта из библиографической записи – «интегрированный файл»(3) 12
Web-програмування та web-дизайн iconТехническая документация web ирбис64 и web ирбис32
Команда чтения внутреннего двоичного объекта из библиографической записи – «интегрированный файл»(3) 14
Додайте кнопку на своєму сайті:
Документи


База даних захищена авторським правом ©zavantag.com 2000-2013
При копіюванні матеріалу обов'язкове зазначення активного посилання відкритою для індексації.
звернутися до адміністрації
Документи