Перейти на главную страницу
Описание структуры документа XML, выполненное средствами DTD, очень скоро перестало удовлетворять разработчиков. Потребовалось более точное описание схемы документа, учитывающее тип содержимого элемента, количество повторений вложенного элемента и другие подробности.
В мае 2001 года консорциум W3C рекомендовал описывать структуру документов XML на новом языке описания схем XSD (XML Schema Definition Language). На этом языке записывается схема XML (XML Schema), описывающая конструкции, использованные в документе XML.
Язык XSD создан как реализация XML. Это значит, что схема XML сама записывается в виде документа XML. Ее элементы называют компонентами (components), чтобы отличить их от элементов описываемого документа XML. Корневой компонент схемы носит имя schema. Компоненты схемы описывают элементы XML и определяют различные типы элементов. Рекомендация схемы XML, которую можно посмотреть по адресу http:// www.w3.org/XML/Schema/, перечисляет 13 типов компонентов, но наиболее важны компоненты, определяющие простые и сложные типы элементов, сами элементы и их атрибуты.
Язык XSD различает простые и сложные элементы XML. Простыми (simple) элементами описываемого документа XML считаются элементы, не содержащие атрибутов и вложенных элементов. Соответственно, сложные (complex) элементы содержат атрибуты и/или вложенные элементы. Схема XML определяет простые типы — типы простых элементов, и сложные типы — типы сложных элементов.
Язык описания схем содержит множество встроенных простых типов, перечисленных в следующем разделе.
Встроенные типы языка описания схем XSD позволяют записывать двоичные и десятичные целые числа, вещественные числа, дату и время, строки символов, логические значения, адреса URI. Рассмотрим их по порядку.
Вещественные числа в языке XSD разделены на три типа: decimal, float и double.
Тип decimal составляют вещественные числа, записанные с фиксированной точкой: 123.45, -0.1234567689345 и т.д. Фактически хранятся два целых числа. Одно число представляет мантиссу, другое — порядок вещественного числа. Спецификация языка XSD не ограничивает количество цифр в мантиссе, но требует, чтобы можно было записать не менее 18 цифр. При обработке документа средствами технологии Java этот тип легко реализуется, например, классом java.math.BigDecimal, входящим в стандарт Java API.
Типы float и double соответствуют стандарту IEEE754-85 и одноименным типам Java. Они записываются с фиксированной или с плавающей десятичной точкой. Например, 34.567, -45.67, 1е-5, 34.58е14.
Основной целый тип integer понимается как подтип типа decimal, содержащий числа с нулевым порядком. Это целые числа с любым количеством десятичных цифр: -34567, 123456789012345 и т.д. При использовании средств Java для обработки документа этот тип легко реализуется классом Java.math.BigInteger.
Типы long, int, short и byte полностью соответствуют одноименным типам Java. Они понимаются как подтипы типа integer, типы более коротких чисел считаются подтипами более длинных чисел, например тип byte — это подтип типа short, оба они подтипы типа int и т. д.
Значения типа byte, как следует из его названия, занимают один байт и изменяются от -128 до 127. Тип short занимает два байта, его значения лежат в диапазоне от -32768 до +32767. Числа типа int хранятся в четырех байтах и меняются от -2147483648 до +2147483647. Наконец, тип long располагается в восьми байтах, его значения от -9223372036854775808 до +9223372036854775807.
Типы nonPositivelnteger и negativelnteger — подтипы типа integer — составлены из неположительных и отрицательных чисел соответственно с любым количеством цифр.
Типы nonNegativelnteger и positivelnteger— подтипы типа integer— со-ставлены из неотрицательных и положительных чисел соответственно с любым количеством цифр.
У типа nonNegativelnteger есть подтипы целых чисел без знака unsignedLong, unsignedlnt, unsignedShort и unsignedByte.
Строки символов
Основной символьный тип string описывает произвольную строку символов Unicode. Его можно реализовать средствами Java, используя класс Java.lang.String.
Тип normalizedString — подтип типа string — это строки, не содержащие символов перевода строки '\n', возврата каретки '\г' и горизонтальной табуляции '\t'.
В строках типа token — подтипа типа normalizedString — нет, кроме того, начальных и завершающих пробелов и нескольких подряд идущих пробелов.
В типе token выделены три подтипа. Подтип language определен для записи названия языка согласно рекомендации RFC 1766, например, ru, en, de, fr. Подтип nmtoken используется только в атрибутах для записи их перечисляемых значений. Подтип name составляют имена XML — последовательности букв, цифр, дефисов, точек, двоеточий, знаков подчеркивания, начинающиеся с буквы (кроме зарезервированной последовательности букв X, х, M, m, L, 1 в любом сочетании регистров) или знака подчеркивания. Мы видели в предыдущих главах, что имена, начинающиеся со строки xml, используются самой спецификацией XML, например, имя атрибута xmlns. Двоеточие в значениях типа name применяется для выделения префикса в уточненных именах при использовании пространства имен.
Из типа name выделен подтип NCName (Non-Colonized Name) имен, не содержащих двоеточия, в котором, в свою очередь, определены три подтипа: id, entity, idref, — описывающие идентификаторы XML, сущности и перекрестные ссылки на идентификаторы.
Тип duration описывает промежуток времени, например, запись P1Y2M3DT10H30M45S означает один год (1Y), два месяца (2м), три дня (3d), десять часов (10H), тридцать минут (30M) и сорок пять секунд (45S). Запись может быть сокращенной, например, Р120М означает 120 месяцев, а Т120М — 120 минут.
Тип dateTime содержит дату и время в формате CCYY-MM-DDThh:mm:ss, например, 2003-04-25Т09:30:05. Остальные типы выделяют какую-либо часть даты или времени.
Тип time содержит время в обычном формате hh:mm:ss.
Тип date содержит дату в формате ccyy-mm-dd.
Тип gYearMonth выделяет год и месяц в формате ccyy-mm.
Тип gMonthDay содержит месяц и день месяца в формате -mm-dd.
Тип gYear означает год в формате ccyy, тип gMonth - месяц в формате -мм-, тип gDay — день месяца в формате -dd.
Двоичные целые числа записываются либо в шестнадцатеричной форме без всяких дополнительных символов: 0B2F, 356С0А и т. д., это тип hexBinary, либо в кодировке Base64, это тип base64Binary.
Еще три встроенных простых типа описывают значения, часто используемые в документах XML.
Адреса URI относятся к типу anyURI.
Расширенное имя тега или атрибута (qualified name), т. е. имя вместе с префиксом, отделенным от имени двоеточием, — это тип QName.
Обозначение notation описания DTD выделено как отдельный простой тип схемы XML. Его используют для записи математических, химических и других символов, нот, азбуки Бройля и прочих обозначений.
Определение простых типов
В схемах XML с помощью встроенных типов можно тремя способами определить новые типы простых элементов. Они вводятся как сужение (restriction) встроенного или ранее определенного простого типа, список (list) или объединение (union) простых типов.
Простой тип определяется компонентом схемы simpleType, имеющим вид
Сужение
Сужение простого типа определяется компонентом restriction, в котором атрибут base указывает сужаемый простой тип, а в содержимом задаются ограничения, выделяющие определяемый простой тип. Например, почтовый индекс zip можно определить как шесть арабских цифр следующим образом:
Можно дать другое определение простого типа zip как целого положительного числа, находящегося в диапазоне от 100000 до 999999:
Теги
— регулярное выражение;
В тегах-фасетках можно записывать следующие атрибуты, называемые базисными фасетками (fundamental facets):
□ ordered — задает упорядоченность определяемого типа, принимает одно из трех значений:
□ cardinality — задает конечность или бесконечность типа значением finite или countably infinite;
□ numeric — показывает, числовой этот тип или нет, значением true или false.
Как видно из приведенных выше и ниже примеров, в одном сужении может быть несколько ограничений-фасеток. При этом фасетки
Простой тип-список — это тип элементов, в теле которых записываются через пробел несколько значений одного и того же простого типа. Например, в документе XML может встретиться такой элемент, содержащий список целых чисел:
Список определяется компонентом list, в котором атрибутом itemType указывается тип элементов определяемого списка. Тип элементов списка можно определить и в содержимом элемента list. Например, показанный выше элемент документа XML days можно определить в схеме так:
а использованный при его определении тип listOfInteger задать как список не более чем из пяти целых чисел следующим образом:
При определении списка можно применять фасетки
Простой тип-объединение определяется компонентом union, в котором атрибутом memberTypes можно указать имена объединяемых типов. Например:
Другой способ — записать в содержимом компонента union определения простых типов, входящих в объединение. Например:
.
После этого атрибут size можно использовать, например, так:
Глава K/font> Простой TeKCT
Упражнения
Элементы, из которых будет состоять документ XML, объявляются в схеме компонентом element:
Значение по умолчанию необязательных атрибутов minOccurs и maxoccurs равно 1. Это означает, что если эти атрибуты отсутствуют, то элемент должен появиться в документе XML ровно один раз. Например:
Указание типа элемента в атрибуте type удобно, если это встроенный простой тип или тип, определенный заранее. Тогда в атрибуте type можно записать только имя типа.
Если же тип элемента определяется здесь же, то определение типа элемента лучше вынести в содержимое компонента element:
Определение типа элемента
Объявление атрибута элемента тоже несложно:
изе="обязательность атрибута" default="значение по умолчанию" /> Необязательный атрибут use принимает три значения:
optional — описываемый атрибут необязателен (это значение по умолча
нию);
required — описываемый атрибут обязателен;
prohibited — описываемый атрибут неприменим. Это значение полезно
при определении подтипа, чтобы отменить некоторые атрибуты базового
типа.
Например:
Если описываемый атрибут необязателен, то атрибутом default можно задать его значение по умолчанию:
Определение типа атрибута, — а это должен быть простой тип, — можно вынести в содержимое элемента attribute:
Тип атрибута
Объявите элементы, встретившиеся в листингах главы /, и их атрибуты.
Напомним, что тип элемента называется сложным, если в элемент вложены другие элементы и/или в открывающем теге элемента есть атрибуты.
Сложный тип определяется компонентом complexType, имеющим вид:
Определение типа
Необязательный атрибут name задает имя типа, а в содержимом компонента complexType описываются элементы, входящие в сложный тип, и/или атрибуты открывающего тега.
Определение сложного типа можно разделить на три группы:
Проще всего определяется тип пустого элемента — элемента, не содержащего тела, а содержащего только атрибуты в открывающем теге. Таков, например, элемент name листинга 1.2. Каждый атрибут объявляется одним компонентом attribute, как в предыдущем разделе, например:
После этого определения можно в схеме объявить элемент image типа imageType:
а в документе XML использовать это объявление:
Немного сложнее описание элемента, содержащего тело простого типа и атрибуты в открывающем теге. Этот тип отличается от простого типа только наличием атрибутов и определяется компонентом simpiecontent. В теле этого компонента должен быть либо компонент restriction, либо компонент extension, атрибутом base задающий тип (простой) тела описываемого элемента.
В компоненте extension указываются атрибуты открывающего тега описываемого элемента. Все вместе выглядит так, как в следующем примере:
type="xsd:nonNegativeInteger" />
Эту конструкцию можно описать словами так: "Определяется тип calcResuitType элемента, тело которого содержит значения встроенного простого типа xsd: decimal. Простой тип расширяется тем, что к нему добавляются атрибуты unit И precision".
Если в схеме объявить элемент result этого типа следующим образом:
то в документе XML можно написать:
В компоненте restriction, кроме атрибутов, описывается простой тип содержимого элемента и/или фасетки, ограничивающие тип, заданный атрибутом base. Например:
Определите тип элемента city из листинга 1.2.
Если значениями определяемого сложного типа будут элементы, содержащие вложенные элементы, как, например, элементы address, phone-list
листинга 1.2, то перед тем, как перечислять их описания, надо выбрать модель группы (model group) вложенных элементов. Дело в том, что вложенные элементы, составляющие определяемый тип, могут появляться или в определенном порядке, или в произвольном порядке, кроме того, можно выбирать только один из перечисленных элементов. Эта возможность и называется моделью группы элементов. Она определяется одним из трех компонентов: sequence, all ИЛИ choice.
Компонент sequence применяется в том случае, когда перечисляемые элементы должны записываться в документе "в определенном порядке. Пусть, например, мы описываем книгу. Сначала определяем тип:
Потом описываем элемент:
Элементы author, title, pages И publisher ДОЛЖНЫ ВХОДИТЬ В элемент book именно в таком порядке. В документе XML надо писать:
fleTCKaH juiTepaTypa
ЕСЛИ Же ВМеСТО компонента xsd: sequence записать КОМПОНеНТ xsd:all, ТО
элементы author, title, pages и publisher можно перечислять в любом порядке.
Компонент choice применяется в том случае, когда надо выбрать один из нескольких элементов. Например, при описании журнала вместо издатель-
ства, описываемого элементом publisher, надо записать название журнала. Это можно определить так:
Как видно из этого примера, компонент choice можно вложить в компонент sequence или, наоборот, вложить компонент sequence в компонент choice. Такие вложения можно проделать сколько угодно раз. Кроме того, каждая группа в этих моделях может появиться сколько угодно раз, т. е.
В компоненте choice ТОЖе МОЖНО записать атрибут maxOccurs="unbounded".
Модель группы all отличается в этом от моделей sequence и choice. В компоненте all Не допускается использование компонентов sequence И choice. Аналогично, в компонентах sequence и choice нельзя применять компонент all. Каждый элемент, входящий в группу модели all, может появиться не более одного раза, т. е. атрибут maxoccurs этого элемента может равняться только единице.
При определении сложного типа можно воспользоваться уже определенным, базовым, сложным типом, расширив его дополнительными элементами, или, наоборот, удалив из него некоторые элементы. Для этого необходимо применить компонент compiexcontent. В этом компоненте, так же как и в компоненте simpieContent, записывается либо компонент extension, если надо расширить базовый тип, либо компонент restriction, если нужно его сузить. Базовый тип указывается атрибутом base, так же как и при записи компонента simpieContent, но теперь это должен быть сложный, а не простой тип!
Расширим, например, определенный выше тип Ьооктуре, добавив год издания — элемент year:
При сужении базового типа компонентом restriction надо перечислить те элементы, которые останутся после сужения. Например, оставим в типе newbookType только автора и название книги из типа Ьооктуре:
Это описание выглядит странно. Почему надо заново объявлять все элементы, остающиеся после сужения? Не проще ли определить новый тип?
Дело в том, что в язык XSD внесены элементы объектно-ориентированного программирования, которых мы не будем касаться. Расширенный и суженный типы связаны со своим базовым типом отношением наследования, и к ним можно применить операцию подстановки. У всех типов языка XSD есть общий предок — базовый тип апуТуре. От него наследуются все сложные типы. Это подобно тому, как у всех классов Java есть общий предок — класс object, а все массивы наследуются от него. От базового типа апуТуре наследуется и тип anySimpieType — общий предок всех простых типов.
Таким образом, сложные типы определяются как сужение типа апуТуре. Если строго подходить к определению сложного типа, то определение типа bookType, сделанное в начале предыдущего раздела, надо записать так:
Рекомендация языка XSD позволяет сократить эту запись, что мы и сделали в предыдущем разделе. Это подобно тому, как в Java мы опускаем слова "extends object" в заголовке описания класса.
Закончим на этом описание языка XSD и перейдем к примерам.
Пример: схема адресной книги
В листинге 3.1 записана схема документа, приведенного в листинге 1.2.
! Листинг 3.1. Схема XSD записной книжки
use="optional" /> use="optional" /> use="required" />
Листинг 3.1, как обычный документ XML, начинается с пролога, показывающего версию XML и определяющего стандартное пространство имен схемы XML с идентификатором https://www.w3.org/2001/XMLSchema. С этим идентификатором связан префикс xsd. Конечно, префикс может быть другим, часто пишут префикс ха.
Все описание схемы нашей адресной книжки заключено в третьей строке, в которой указано, что адресная книга состоит из одного элемента с именем notebook, имеющего сложный тип notebookType. Этот элемент должен появиться в документе ровно один раз. Остальная часть листинга 3.1 посвящена описанию типа этого элемента и других типов.
Определение сложного типа notebookType несложно (простите за каламбур). Оно занимает три строки листинга, не считая открывающего и закрывающего тега, и просто говорит о том, что данный тип составляют несколько элементов person типа personType.
Определение типа personType немногим сложнее. Оно означает, что этот
ТИП составляют четыре элемента: name, birthday, address И phone-list. Для
элемента name сразу же объявлены необязательные атрибуты first и second простого типа string, определенного в пространстве имен xsd. Тип обязательного атрибута surname — тоже string.
Далее в листинге 3.1 определяются оставшиеся типы addressType, phone-listType и ruDate. Необходимость определения простого типа ruDate возникает потому, что встроенный в схему XML тип date предписывает записывать дату в виде 2003-02-22, а в России принят формат 22.02.2003. Тип ruDate определяется как сужение (restriction) типа string с помощью шаблона. Шаблон (pattern) для записи даты в виде ДД.ММ.ГГГГ задается регулярным выражением.
Все описанные в листинге 3.1 типы используются только один раз. Поэтому необязательно давать типу имя. Схема XML, как говорилось выше, позволяет определять безымянные типы. Такое определение дается внутри описания элемента. Именно так в листинге 3.1 описаны атрибуты элемента name. В листинге 3.2 показано упрощенное описание схемы адресной книги.
! Листинг 3.2. Схема документа XML с безымянными типами
type='xsd:string' use='optional' />
Еще одно упрощение можно сделать, используя пространство имен по умолчанию. Посмотрим, какие пространства имен применяются в схемах XML.
Имена элементов и атрибутов, используемые при записи схем, определены в пространстве имен с идентификатором https://www.w3.org/2001/XMLSchema. Префикс имен, относящихся к этому пространству, часто называют xs или xsd, как в листингах 3.1 и 3.2. Каждый анализатор "знает" это пространство имен и "понимает" имена из этого пространства.
Можно сделать это пространство имен пространством по умолчанию, но тогда надо задать пространство имен для определяемых в схеме типов и элементов. Для удобства такого определения введено понятие целевого про-
странства имен (target namespace). Идентификатор целевого пространства имен определяется атрибутом targetNamespace, например:
После такого определения имена, определяемые в этой схеме, будут относиться к новому пространству имен с идентификатором https://some.firm.com /2003/ntbNames. Так сделано в листинге 3.3. Для упрощения записи в нем стандартное пространство имен схемы XML с идентификатором https:// www.w3.org/2001/XMLSchema сделано пространством имен по умолчанию. Имена, относящиеся к целевому пространству, снабжены префиксом ntb, чтобы они не попали в пространство имен по умолчанию.
| Листинг 3.3. Схема документа XML с целевым пространством имен
taigotNamespace»'https://some.firm.com/2003/ntbNames' X!- !:..; :ntb= 'http: //some. firm, com/2003/ntbNames '>
■ rplexType> vsequence>
Ottribute name='second'
type='string' use='optional' />
Ottribute name=' surname '
type='string' use='required' />
Поскольку в листинге 3.3 пространством имен по умолчанию сделано пространство https://www.w3.org/2001/XMLSchema, префикс xsd не нужен.
Следует заметить, что в целевое пространство имен попадают только глобальные имена, чьи описания непосредственно вложены в корневой элемент schema. Это естественно, потому что только глобальными именами можно воспользоваться далее в этой или другой схеме. В листинге 3.3 лишь одно глобальное имя notebook. Вложенные имена name, address и др. только ассоциированы с глобальными именами.
В схемах и документах XML часто применяется еще одно стандартное пространство имен. Рекомендация языка XSD определяет несколько атрибутов:
type, nil, schemaLocation, noNamespaceSchemaLocation, Которые применяются
не только в схемах, а и непосредственно в описываемых этими схемами документах XML, называемых экземплярами схем (XML schema instance). Имена этих атрибутов относятся к пространству имен https://www.w3.org /2001/XMLSchema-instance. Этому пространству имен чаще всего приписывают префикс xsi, например:
В создаваемую схему можно включить файлы, содержащие другие схемы. Для этого есть два элемента схемы: include и import. Например:
Включаемый файл задается атрибутом xsi:schemaLocation. В примере он использован для того, чтобы включить в создаваемую схему содержимое файла names.xsd. Файл должен содержать схему с описаниями и определениями из того же пространства имен, что и в создаваемой схеме, или без пространства имен, т. е. в нем не использован атрибут targetNamespace. Это удобно, если мы хотим добавить к создаваемой схеме определения схемы names.xsd или просто разбить большую схему на два файла. Можно представить себе результат включения так, как будто содержимое файла names.xsd всего лишь записано на месте элемента include.
Перед включением файла можно изменить некоторые определения, приведенные в нем. Для этого используется элемент redefine, например:
Если же включаемый файл содержит имена из другого пространства имен, то надо воспользоваться элементом схемы import. Например, пусть файл A.xsd начинается со следующих определений:
а файл B.xsd начинается с определений:
Мы решили включить эти файлы в новый файл C.xsd. Это делается так:
xmlns:prl="https://some.firm.com/someNames"
xmlns:pr2="https://some.firm.com/anotherNames">
После этого в файле C.xsd можно использовать имена, определенные в файлах A.xsd и B.xsd, снабжая их префиксами pri и рг2 соответственно.
Элементы include и import следует располагать перед всеми определениями схемы.
Значение атрибута xsi:schemaLocation — строка URI, поэтому файл с включаемой схемой может располагаться в любом месте Интернета.
Программе-анализатору, проверяющей соответствие документа XML его схеме, надо как-то указать файлы (один или несколько), содержащие схему документа. Это можно сделать разными способами. Во-первых, можно подать эти файлы на вход анализатора. Так делает, например, проверяющий анализатор XSV (XML Schema Validator) (ftp://ftp.cogsci.ed.ac.uk/pub/XSV/):
$ xsv ntb.xml ntbl.xsd ntb2.xsd
Во-вторых, можно задать файлы со схемой как свойство анализатора, устанавливаемое методом setpropertyo, или значение переменной окружения анализатора. Так делает, например, проверяющий анализатор Xerces.
Эти способы удобны тогда, когда документ в разных случаях нужно связать с различными схемами. Если же схема документа фиксирована, то ее
удобнее указать прямо в документе XML. Это делается одним из двух способов:
□ Если элементы документа не принадлежат никакому пространству имен
и записаны без префикса, то в корневом элементе документа записыва
ется атрибут noNamespaceSchemaLocation, указывающий расположение
файла со схемой в форме URI:
не следует ИСПОЛЬЗОВать атрибут targetNamespace.
□ Если же элементы документа относятся к некоторому пространству
xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= "https://some.firm.com/someNames A.xsd
https://some.firm.com/anotherNames B.xsd" xmlns:prl="https://some.firm.com/someNames" xmlns:pr2-"https://some.firm.com/anotherNames"> После этого в документе можно использовать имена, определенные в схемах A.xsd и B.xsd, снабжая их префиксами pri и рг2 соответственно.
Даже из приведенного выше краткого описания языка XSD видно, что он получился весьма сложным и запутанным. Есть уже несколько книг, полностью посвященных этому языку. Их объем ничуть не меньше объема всей этой книги. Есть и другие, более простые языки описания схемы документа XML. Наибольшее распространение получили следующие из них:
имен, то применяется атрибут schemaLocation, в котором через пробел
перечисляются пространство имен и расположение файла со схемой,
описывающей это пространство имен. Продолжая пример предыдущего
раздела, можно написать:
Другие языки описания схем
Schematron — https://www.ascc.net/xml/resource/schematron/;
RELAX NG — Regular Language Description for XML, New Generation,
https://www.oasis-open.org/committees/relax-ng/, этот язык возник как
слияние языков Relax и TREX;
Relax — https://www.xml.gr.jp/relax/;
П TREX — Tree Regular Expressions for XML, https://www.thaiopensource.com/trex/;
□ DDML — Document Definition Markup Language, известный еще как XSchema, https://purl.oclc.org/NET/ddml/.
Менее распространены языки DCD (Document Content Description), SOX (One's Schema for Object-Oriented XML), XDR (XML-Data Reduced).
Хороший обзор языков описания схем представлен на странице http://www.oasis-open.org/cover/schemas.html.
Описание структуры документа xml, выполненное средствами dtd, очень скоро перестало удовлетворять разработчиков. Потребовалось более точное описание схемы документа, учитывающее ти
14 12 2014
1 стр.
Описание программатора и схемы, требования к оборудованию
06 10 2014
1 стр.
Наименование документа: Тренинг по профилактике алкогольной и наркотической зависимости у подростков
12 10 2014
1 стр.
Рисунок 15 – Напряжённое состояние поперечин несущей системы. Нагрузка Рисп=10000 Н
14 10 2014
1 стр.
ФорматАбзац устанавливает параметры формата абзацев выделенного фрагмента или текущего абзаца текстового документа, а именно: поля отступов, междустрочный интервал внутри абзаца,
12 10 2014
1 стр.
Ф. Бартлеттом концепции схемы, демонстрация влияния этой теоретической конструкции на развитие когнитивной психологии, и помещение принципа схемы в контекст современных концепций п
11 10 2014
3 стр.
Техническое описание и инструкция по эксплуатации. Схемы электрические принципиальные. Альбом №2
23 09 2014
11 стр.
Посредством этой примерной доски фотографии можно проверить, наполняет ли фотография все необходимые критерии. Соблюдение этих критериев нужно делать возможным для наилучшего узнав
14 12 2014
1 стр.