CMemFile(BYTE* lpBuffer, UINT nBufferSize,

UINT nGrowBytes=0);

Параметр lpBuffer указывает на буфер, который будет использоваться для файла. Размер буфера определяется параметром nBufferSize.

Необязательный параметр nGrowBytes используется более комплексно, чем в первом конструкторе класса. Если nGrowBytes содержит нуль, то созданный файл будет содержать данные из буфера lpBuffer. Длина такого файла будет равна nBufferSize.

Если nGrowBytes больше нуля, то содержимое буфера lpBuffer игнорируется. Кроме того, если в такой файл записывается больше данных, чем помещается в отведенном буфере, то его размер автоматически увеличивается. Увеличение блока памяти файла происходит по частям по nGrowBytes байт.

Класс CMemFile позволяет получить указатель на область памяти, используемую файлом. Через этот указатель можно непосредственно работать с содержимым файла, не ограничивая себя методами класса CFile. Для получения указателя на буфер файла можно воспользоваться методом Detach. Перед этим полезно определить длину файла (и соответственно размер буфера памяти), вызвав метод GetLength.

Метод Detach закрывает данный файл и возвращает указатель на используемый им блок памяти. Если опять потребуется открыть файл и связать с ним оперативный блок памяти, нужно вызвать метод Attach.

Нужно отметить, что для управления буфером файла класс CMemFile вызывает стандартные функции malloc, realloc и free. Поэтому, чтобы не нарушать механизм управления памятью, буфер lpBuffer должен быть создан функциями malloc или calloc.

Класс CstdioFile

Класс CStdioFile позволяет выполнять буферизированный ввод/вывод в текстовом и двоичном режиме. Для объектов класса CStdioFile можно вызывать практически все методы класса CFile.

В класс CStdioFile входит элемент данных m_pStream, который содержит указатель на открытый файл. Если объект класса CStdioFile создан, но файл еще не открыт, либо закрыт, то m_pStream содержит константу NULL.

Класс CStdioFile имеет три различных конструктора. Первый конструктор класса CStdioFile не имеет параметров. Этот конструктор только создает объект класса, но не открывает никаких файлов. Чтобы открыть файл, надо вызвать метод Open базового класса CFile.

Второй конструктор класса CStdioFile можно вызвать, если файл уже открыт и нужно создать новый объект класса CStdioFile и связать с ним открытый файл. Этот конструктор можно использовать, если файл был открыт стандартной функцией fopen. Параметр метода должен содержать указатель на файл, полученный вызовом стандартной функции fopen.

Третий конструктор можно использовать, если надо создать объект класса CStdioFile, открыть новый файл и связать его с только что созданным объектом.

Для чтения и записи в текстовый файл класс CStdioFile включает два метода: ReadString и WriteString. Первый метод позволяет прочитать из файла строку символов, а второй метод - записать.

6. Реализация

В настоящий момент система находится в опытной эксплуатации, по результатам которой производится дальнейшее совершенствование системы.

· База данных состоит из 9 таблиц.

· Объем кода sql скриптов (построения структуры БД) составляет: 12 kb.

· Объем программных кодов на ASP составляет 84 kb.

· Объем программных кодов на Visual C++ - составляет 75 kb.

6.1. Тестирование

С помощью программного обеспечения (Iolo Macromagic 4.1), эмулирующего пользовательскую активность, было проведено стресс тестирование, в результате которого было выявлено рекомендуемое и максимальное количество пользователей, которое может работать с системой одновременно - 240 клиентских сеансов.

Тестирование проводилось в основном по «белому ящику» силами разработчика системы.

Тестирование по «черному ящику» и апробация системы происходит в ТОИ ДВО РАН.

6.2. Пример работы системы

Этап 1:

Для сотрудников Лаборатории средств и методов спутниковых наблюдений, входящей в состав ТОИ ДВО РАН (Тихоокеанский океанологический институт им. В.И. Ильичева Дальневосточного отделения Российской академии наук) необходимо ежедневное получение информации (в shape формате) о ветре над акваторией дальневосточных морей. Эта информация находится на сайте Physical Oceanography Data Active Archive Center (California Institute of Technology).

Решение:

Сотрудник лаборатории обработки спутниковой информации (manager) обращается к администратору системы (сотруднику Лаборатории комплексного анализа океанологической информации) (admin), с пожеланием добавить новый ресурс, предоставляя следующие сведения: информация находится по адресу в этом ftp-каталоге существуют файлы с расширениями .gif и .gz (попарно на одни сутки), появляются один раз в четверо суток. Внутри .gz файла лежит файл в формате hdf на весь земной шар.

Admin заводит ресурс, создает учетную запись менеджера ресурса (manager), задает правила для обработки ресурса, инициализирует сбор данных о ресурсе.

Приблизительный размер каждого .gz файла 6 мб, размер каждого .gif файла 100 kb.

Через неделю работы системы менеджеру (manager) пришло сообщение, что система не смогла получить данные за указанный промежуток времени (ResponseTimeOutRes) в связи с медленной связью между ТОИ и Physical Oceanography Data Active Archive Center, поэтому менеджер решил изменить (увеличить) параметр ResponseTimeOutRes, после чего система стала успешно скачивать файлы за определенный промежуток времени.

Результат:

На локальном сервере 3 дня информация не обновляется и каждый 4-й день появляется восемь файлов (не преобразованных).

Этап 2:

Менеджер решил автоматизировать процесс обработки файлов на стороне сервера: именно распаковку файла, преобразование формата, вырезание географического региона.

Решение:

Он настраивает правила следующим образом:

· Распаковать gz файл -> получить hdf файл

· Преобразовать hdf файл в shape

· Вырезать определенный географический регион по определенным координатам

Результат:

На локальном сервере для всех полученных данных появились обработанные файлы, а при каждом успешном скачивании нового файла с удаленного источника автоматически стал генерироваться обработанный с помощью этих правил файл.

Этап 3:

Как оказалось для сотрудников Лаборатории моделирования физических процессов в океане, существует необходимость работы с этими данными, в результате они могут использовать локальную информацию как пользователи с правами viewer.

6.3. Интерфейс

Интерфейс системы является интуитивно понятным любому пользователю, это было доказано в ходе опытной эксплуатации.

Рассмотрим основные состояния системы, с точки зрения интерфейса.

Состояние «Вход в систему»

Состояние «Просмотр и редактирование менеджеров и их ресурсов»

Состояние «Просмотр и редактирование менеджеров»

Состояние «Просмотр и редактирование ресурсов»

Состояние «Управление менеджерами и их ресурсами»

Состояние «Изменение параметров ресурса»

Состояние «Изменение параметров пользователя»

Состояние «Управление и просмотр файлов ресурса»

Состояние «Результаты поиска файлов»

Состояние «Результат поиска текста в файлах»

Заключение

Таким образом, в дипломной работе получены следующие основные результаты:

· проведено исследование предметной области;

· рассмотрены имеющиеся решения проблемы;

· выделена малоисследованная часть ПО;

· в тесном контакте с заказчиком разработаны требования к системе;

· разработаны модель данных, дизайн и интерфейс системы;

· разработана архитектура системы;

· разработана концепция интерфейса;

· спроектирована БД системы;

· реализована система мониторинга и обработки информации;

· разработаны и продолжают дорабатываться основные модули системы;

· созданы справочная система и проектная документация.

Разработанная система позволяет решать следующие задачи:

· Предоставление сервиса, который хранит список центров удаленных данных;

· Осуществление доступа к удаленным данным по протоколам ftp и http;

· Выполнение с некоторой периодичностью, либо по требованию пользователя запросов на получение удаленных данных;

· Проверка локальных данных на актуальность;

· Формирование наиболее возможного метаописания этих ресурсов: дата создания, дата изменения, формат файла, авторские права, размер, дополнительное описание;

· Предоставление доступа пользователей к полученным данным, и их предобработка на сервере через WEB интерфейс;

· Предоставление возможности поиска по базе локальных информационных ресурсов.

В настоящий момент в системе зарегистрировано более 10 менеджеров ресурсов и около 23 ресурсов.

Системой Remote Data Searcher пользуются сотрудники Лаборатории средств и методов спутниковых наблюдений, входящей в состав ТОИ ДВО РАН (Тихоокеанского океанологического института им. В.И. Ильичева Дальневосточного отделения Российской академии наук), а также сотрудники других лабораторий.

По имеющимся на сегодняшний день результатам можно говорить об успешной реализации проекта.

Список литературы

1. Гарольд Э.Р., Минс С., «XML - справочник», СПБ, 2002

2. Каба М.А., MySQL и Perl: коммерческие приложения для Интернета. Учебный курс, Питер-Пресс, 2002

3. Кирсанов Д. WEB-дизайн. -- СПб.: Символ-Плюс, 2002.

4. Когаловский М.Р. XML: сферы применений. - М.: Изд. “Открытые системы”. Апрель 2001. - с. 10-12.

5. Котеров Д., Самоучитель PHP, - СПб.: BHV-Санкт-Петербург, 2001.

6. Лейз С., «Возникновение языка «географической» разметки Geographic Markup Language», Журнал «Компьютера №5/2002»

7. Леоненков А.В. Самоучитель UML. - СПб.: BHV-Санкт-Петербург, 2001.

8. Павлов А. CGI-программирование: учебный курс. СПб.: Питер, 2000.

9. Питтс Н. XML за рекордное время - М.: Мир, 2000.

10. Грегори К., Использование Visual C++ 6, М. Мир,2002.

11. Тихомиров А, Мешков Ю., Visual C++, 2 изд., - СПб.: BHV-Санкт-Петербург, 2001.

12. Сайт, посвященный проблемам стандартизации ГИС-технологий. http://www.opengis.org/

13. Хокинс С. Администрирование Web-сервера Apache и руководство по электронной коммерции.: Пер. с англ. -- М.: Издательский дом «Вильямс», 2001.

14. Шварц Р., Кристиансен Т. Изучаем Perl: Издательская группа BHV, 1999.

15. Эдди С.Э. XML: справочник. - СПб.: Питер, 1999. - 480 с.

16. Электронная справочная система для программных средств: MapInfo Metadata Browser и ESRI ARCCatalog.

17. «XML & GML», Журнал PC Week, № 2/2002

18. RFC HTTP 1.0 - rfc1945, HTTP 1.1 - rfc2068, http://www.w3.org.pub/pub/WWW

19. Berners-Li T., Fielding R., Irvine U.C., Masinter L. Uniform Resource Identifiers (URI): General Syntax. RFC 2396. August 1998.

20. Extensible Markup Language (XML) 1.0 (Second Edition). W3C Recommendation. 2000, http://www.w3.org/TR/2000/REC-xml-20001006.

21. Extensible Stylesheet Language (XSL) 1.0. W3C Recommendation. 2002, http://www.w3.org/TR/WD-xsl

22. Extensible Stylesheet Language (XSL). Version 1.0. W3C Working Draft. 2000. http://www.w3.org/TR/2000/WD-xsl-20001018.

23. OMG Unified Modeling Language Specification. Version 1.4, Object Management Group, September 2001, http://www.omg.org/technology/documents/formal/uml.htm

24. PostgreSQL at a glance. - PostgreSQL. http://www.ru.postgresql.org/features.html

25. Resource Description Framework (RDF). Model and Syntax Specification. W3C Recommandation. 1999. http://www.w3.org/TR/REC-rdf-syntax/.

26. Resource Description Framework (RDF). Schema Specification 1.0. W3C Recommandation 2000. http://www.w3.org/TR/2000/CR-rdf-schema-20000327.

27. Semantic Web Activity: Resource Description Framework (RDF). http://www.w3.org/RDF/

28. What does this mean Semantic Web, www.w3.org/DesignIssues/Semantic.html

29. What is MySQL? - MySQL: the world's most popular Open Source Database. http://www.mysql.org/documentation/mysql/bychapter/manual_Introduction.html

30. XML Protocol (XMLP) Requirements. W3C, 19 March 2001. http://www.w3.org/TR/2000/REC-xml-20001006.

31. XSL Transformations (XSLT). Version 1.0. W3C Recommandation 1999. http://www.w3.org/TR/1999/REC-xslt-19991116.

32. Спецификация стандартов метаданных ЕСИМО и CSDGM, 2003

Приложение 1

Глоссарий

RDF - Resource Description Framework - структура описания ресурсов.

XSLT - Extensible Stylesheet Language Transformations, расширяемые стилевые таблицы для преобразования языков, описывает преобразования одного документа в другой в рамках того же или другого XML словаря.

Метаданные (metadata) - это информация о документе, понимаемая компьютером (machine understandable), данные о данных.

DTD - Document Type Definition, определением типа документов.

XML - eXtensible Markup Language, расширенный язык разметки.

URL (Uniform Resource Locator) - унифицированный указатель информационного ресурса (стандартизованная строка символов, указывающая местонахождение документа в сети Internet)

ГИС - Географическая информационная система (geographic(al) information system, GIS, spatial information system) - син. геоинформационная система, ГИС - информационная система, обеспечивающая сбор, хранение, обработку, доступ, отображение и распространение пространственно-координированных данных (пространственных данных). ГИС содержит данные о пространственных объектах в форме их цифровых представлений (векторных, растровых, квадротомических и иных), включает соответствующий задачам набор функциональных возможностей ГИС, в которых реализуются операции геоинформационных технологий, поддерживается программным, аппаратным, информационным, нормативно-правовым, кадровым и организационным обеспечением.

HTTP - Hypertext Transfer Protocol (протокол передачи гипертекстов) начинался как один из простейших прикладных протоколов Internet.

FTP - File Transfer Protocol (Протокол передачи файлов) является несколько более сложным и находится в применении намного дольше HTTP. FTP используется для перемещения файлов между двумя или несколькими компьютерами, независимо от их типов.

ASP (Active Server Pages)- ASP позволяют объединить возможности HTML-страниц, команд сценариев и компонентов COM в интерактивных веб-страницах и мощных веб-приложениях, делают удобным и легким процесс их создания и изменения.

Приложение 2

Стандарты гео-метаданных

В последнее десятилетия интенсивно идет создание массивов океанографических данных, созданы сотни исходных, инвертированных и расчетных массивов. Собрана информация о сотнях российских и зарубежных экспедиций. Для обработки этих данных разработаны сотни различных программных средств, на основе которых можно получить тысячи различных расчетных характеристик. Обмен данными (международный, межведомственный и межкорпоративный) всегда сопровождается оценкой их потребительских качеств. Уверенность в поставщике и происхождении данных , возможность быстро найти необходимые сведения, оценить их пригодность для намеченного использования - вот что должны обеспечить пользователю метаданные в первую очередь. Во всем этом потоке информации необходимо очень быстро ориентироваться. И здесь имеющиеся бумажные каталоги, списки, справки, полученные с технических носителей и др. уже не помогают. Во-первых, информация очень быстро изменяется, массивы ежегодно пополняются, корректируются и т.п.. Во-вторых, объем такой информации также относительно большой, так базы сведений об изученности того или иного района оцениваются в десятки мегабайт. В-третьих, справочная информация это основа для перехода на безбумажную технологию обработки океанографической информации. Кроме того, пользователей уже не удовлетворяет полное или выборочное копирование массивов данных, им требуется тонкая выборка по определенным критериям, атрибутов которых иногда нет в исходных массивах данных и об этом заранее неизвестно. [25, 28]

Для поиска данных необходим предварительный анализ справочной информации. Аналогично и с обработкой данных, пользователи хотят включать в обработку только ту информацию, которая удовлетворяет их критериям, например, данные отдельных ведомств или при наличии достаточного объема или полноты данных. Для успешного поиска высококачественных данных необходимы разнообразные метаданные - сведения о массивах данных, форматах их хранения, организациях, хранящих данные, программных средствах их обработки и др. Поэтому такие сведения собираются и хранятся в соответствующих базах метаданных.

Метаданные - это информация, являющаяся вспомогательной, справочной при обработке данных. Это сведения о данных, наблюдательных платформах, проектах, организациях, картах, пособиях, атласах, навигационных объектах (портах, гидрографических знаках, маяках и др.). Характерной чертой метаданных является их относительно невысокая частота изменений. Такое положение связано с тем, что большинство объектов мало изменяется во времени. Тем не менее, важно проследить изменение отдельных объектов во времени, поэтому в состав атрибутов вводится, например, дата разработки прибора, начало их применения и др. Основные данные, необходимые для создания метаданных, содержатся в различного рода технической документации, поэтому они требуют дополнительного упорядочения и формализации. Процесс создания метаданных включает следующие операции: выбор характеристик, разработка структуры базы данных, формализация документов и занесение данных на носитель.

Первые попытки создания массивов справочной информации относятся еще к концу шестидесятых годов. К сожалению, технические возможности того времени не позволили создать полноценные справочные массивы. Была выработана только идея накопления, в первую очередь, справочных сведений о массивах данных находящихся на различных носителях, в мореведческих организациях страны. В конце семидесятых начале восьмидесятых годов вновь вернулись к идее создания массивов справочных сведений. В России была разработано программное средство общего назначения КАТАЛОГ для описания коллекций данных, которое позволяло настраиваться на различные типы справочных сведений. Так на основе этой программной системы было разработано две информационно - справочная системы - общие сведения о массивах гидрометеорологических данных - АИСС КАТАЛОГ и автоматизированный каталог океанографических данных (АКОД), в котором предлагалось отразить как сведения об источниках данных (рейсах НИС и прибрежных станциях), так и детальные сведения о данных на носителях. Эти системы отражали не весь объем справочной информации.

Более широкий подход к созданию метаданных был предпринят в начале восьмидесятых годов в ИК АН Украины при совместной с ВНИИГМИ-МЦД разработке системы управления океанографическими данными. В состав этой системы, кроме сведений о данных, была включена информация о пользователях, запросах, учреждениях, программных средствах и др. То есть состав справочных данных значительно расширился и наступил момент, когда дальнейшее увеличение количества справочных массивов, а также определение их важности уже невозможно без их классификации и обоснования.

Метаданные представляют собой объединение достаточно разнородной по целевому назначению и структуре информационной совокупности. Метаданные обладают рядом специфических особенностей, характерных для всех видов справочной информации:

· Одноразовый ввод информации при первоначальной загрузке метаданных с последующим внесением изменений и многократное ее использование в течение достаточно длительного промежутка времени;

· Относительно малая активность обновления справочной информации, как по частоте, так и по объему корректировки;

· Отделение во времени, по источникам, исполнителям процесса обновления от процесса использования, как следствие, необходимость обеспечения совместимости информации, подлежащей редактированию;

· Наличие четких признаков классификации и группирования информации;

· Необходимость централизации общих сведений о данных и децентрализации локальных, детальных сведений о данных.

Состав и точность описания характеристик объектов метаданных зависит от уровня управления данными, масштабами системы, этапа обработки данных. Справочная информация циркулирует в системе переработки данных каждого учреждения, занимающегося гидрометеорологическим обеспечением экономики страны или находящегося в системе сбора, хранения, обмена и обработки океанографических данных на международном, национальном, ведомственном и корпоративном уровнях. На каждом из этих уровней нужна своя справочная информация.

Так для взаимодействия на международном уровне необходимы сведения о международных соглашениях, массивах данных, предназначенных или переданных в международный обмен, включая сведения о рейсах и станциях, форматах обмена данными, программных средствах их обработки и др. В системе гидрометеорологического обеспечения страны нужны сведения о мореведческих организациях, массивах данных, которые они хранят, программных средствах обработки, форматах сбора и обмена на уровне страны, наблюдательных платформах, наблюдательных сетях и др. На корпоративном уровне необходима детальная информация по массивам (базам данных) в виде сведений о рейсах НИС и их состоянии (в обработке, на каком носителе и т.п.), о состоянии изученности того или иного географического района по различным параметрам. Для лиц, принимающих решения на объектах экономики с использованием информации о состоянии природной среды, в первую очередь необходимы сведения о гидрометеорологической продукции и регламенте ее выпуска, а также возможных типах запросов и решаемых задач. То есть в системе обеспечения имеются как справочные сведения одного класса (сведения о массивах данных, источниках данных, форматах и т.п.), которые можно объединить в одну таблицу, так и специфические для каждого уровня управления данными (сведения о международных соглашениях, конвенциях, законах, наставлениях, руководствах и т.п.).

CSDGM

Стандарт представления метаданных Content Standard for Digital Geospatial Metadata (CSDGM) разработан организацией FGDC (Federal Geographic Data Committee). Состоит из 10 секций:

Таблица 28. Поля стандарта CSDGM

Информационное поле	Назначение
Identification Information	Описание, проекция, широта, долгота, координаты, политика безопасности
Data Quality Information	Время создания, тип источника данных
Spatial Data Organization Information	Используемые географические атрибуты (точечные, векторные, растровые)
Spatial Reference Information	Горизонтальная вертикальная системы, разрешение
Entity and Attribute Information	Детальное описание каждого атрибута
Distribution Information	Условия распространения
Metadata Reference Information	Точки контроля версий
Citation Information	Автор и дистрибьютор информации
Time Period Information	Время обновления
Contact Information	Контактная информация (организация, сотрудник)

ЕСИМО

Информационные ресурсы ЕСИМО классифицируются по видам следующим образом:

· метаданные (классификаторы, кодификаторы и справочники),

· фактографические данные - базы или массивы данных наблюдений и обобщений,

· пространственные данные - электронные морские навигационные и тематические карты/слои,

· графические данные (рисунки, фотографии),

· текстовые данные (документы).

Метаданные (данные о данных) - это такие данные, которые в семантическом плане можно трактовать как содержательные (для человека) или формальные (для информационных технологий) описания информационных ресурсов и их компонентов. Соответственно имеется два раздела метаданных - содержательный и формальный. К содержательному разделу относятся:

· неформальные описания массивов и баз данных, их состава и структуры,

· сведения о наблюдательных сетях, проектах, программах,

· сведения о платформах наблюдений и источниках данных (станциях, постах, судах, рейсах, экспедициях);

· общепринятые классификаторы, словари, кодификаторы;

· сведения о мореведческих организациях, экспертах;

· сведения об алгоритмах, моделях, программных средствах,

· сервисная информация (документация и т.п.).

Формальный раздел метаданных содержит строго организованную, форматированную информацию об информационных ресурсах: их имена, коды, свойства, форматы, адреса хранения и т.п. - все, что необходимо информационным технологиям, чтобы найти информационные ресурсы и правильно их обработать.

Оба раздела метаданных должны быть организованы в виде распределенной базы метаданных, состоящей из метаданных ЕСИМО и множества баз метаданных в объектах ЕСИМО. Главная база хранит основную часть содержательного раздела метаданных, а базы метаданных в объектах ЕСИМО - детализированную содержательную и всю формальную информацию о своих информационных ресурсах.

Фактографические данные включают материалы наблюдений за объектами, а также результаты обработки данных. Фактографические исходные данные возникают как результат выполнения некоторых программ наблюдений или программ исследований того или иного объекта или процесса, которые проводятся в определенные временные периоды и в заданном географическом районе для сфер:

· атмосфера (приземная метеорология);

· гидросфера (гидрологии моря, гидрология устьев рек, грунтовые воды);

· литосфера (геология, геофизика, литодинамика, геоморфология);

· биосфера (биология и растительность моря, устьев рек, береговых зон);

· социосфера (экономика и социальная информация для береговых зон);

· техносфера (инженерно-технологические характеристики).

Фактографические данные обобщений могут быть представлены в виде:

· статистических сведений о фоновых характеристиках гидрометеорологического режима (климатические многолетние данные) для точки или района (квадрата);

· временных рядов гидрометеорологических данных различного временного масштаба осреднения (сутки, декада, месяц, сезон, год, пятилетка);

· полей климатических характеристик в узлах сетки;

· полей синоптических и модельных данных.

· модельных данных в точке (результаты вычислений расчетов по математическим моделям с привлечением многих параметров исходных данных и параметров модели).

Фактографические данные после их обработки (осреднения, интерполяции, фильтрации и др. процедур) могут представляться в виде данных в узлах регулярной сетки. Масштабы пространственно-временного осреднения (обобщения) могут быть различными в зависимости от наличия данных, изменчивости параметров, рассматриваемого района и др. причин. В эту рубрику попадают синоптические данные (давление, температура воздуха, данные о ледовой обстановке и другие параметры), спутниковые данные (волнение, температура воздуха, снежный покров, ледовая обстановка и др.).

Пространственные данные. К таким данным относятся тематические цифровые карты/слои (топографические и тематические - геологические, океанографические и др.), которые создают картографическую основу для работы с атрибутивными данными. При анализе исходной картографической и иной пространственной информации выявляются структуры и особенности использования (картографическая основа, проекции, масштабы, носители данных и т.п.), определяется уровень доступа. Для описания пространственной информации необходимо следующее:

· Общие сведения о картах (картографических и тематических, специальных),

· Параметры карт,

· Сведения о шейп-файлах с картографическими и тематическими картами,

· Исходные картографические данные (координаты береговой линии, глубины - батиметрия, высоты земли и др.),

· Сведения о файлах атрибутивных данных (сведения о банках, маяках и т.п.)

· Базы данных сведений об островах, промышленных объектах,

· Сведения о графической информации (рисунках, фотографиях береговой линии, пляжей, портов и т.п.).

Графические данные - это рисунки, фотографии и сопровождающий их текст. Графические данные хранятся в СУБД в различных форматах (например, в формате BMP) и предоставляется пользователю путем автоматической загрузки этого файла в ГИС. Для поиска таких данных должен быть создан каталог этих данных.

Текстовые данные. Как правило, этот тип данных представляет собой текстовые документы. Для их поиска может быть использован общий каталог баз данных. При этом можно использовать имеющиеся классификации документов. Сами файлы документов можно хранить либо в структуре исходного редактора (например, Word) и предоставлять пользователю путем автоматической загрузки этого документа в Word, либо в виде типа данных Long Raw - двоичных файлов до 2 гигабайт. То есть этот документ может храниться в структуре, состоящей из двух полей: имя файла и содержание самого документа.

Приложение 3

Язык XML

Правила создания XML- документа

В общем случае XML- документы должны удовлетворять следующим требованиям:

· В заголовке документа помещается объявление XML, в котором указывается язык разметки документа, номер его версии и дополнительная информация

· Каждый открывающий тэг, определяющий некоторую область данных в документе обязательно должен иметь своего закрывающего "напарника", т.е., в отличие от HTML, нельзя опускать закрывающие тэги

· В XML учитывается регистр символов

· Все значения атрибутов, используемых в определении тэгов, должны быть заключены в кавычки

· Вложенность тэгов в XML строго контролируется, поэтому необходимо следить за порядком следования открывающих и закрывающих тэгов

· Вся информация, располагающаяся между начальным и конечными тэгами, рассматривается в XML как данные, и поэтому учитываются все символы форматирования (т.е. пробелы, переводы строк, табуляции не игнорируются, как в HTML)

Если XML- документ не нарушает приведенные правила, то он называется формально-правильным и все анализаторы, предназначенные для разбора XML- документов, смогут работать с ним корректно.

Однако кроме проверки на формальное соответствие грамматике языка, в документе могут присутствовать средства контроля над содержанием документа, за соблюдением правил, определяющих необходимые соотношений между элементами и формирующих структуру документа. Например, следующий текст, являясь вполне правильным XML- документом, будет абсолютно бессмысленным:

<country><title>Russia</title><city><title>Novosibirsk</country></title></city>

Для того, чтобы обеспечить проверку корректности XML- документов, необходимо использовать анализаторы, производящие такую проверку и называемые верифицирующими.

На сегодняшний день существует два способа контроля правильности XML- документа: DTD - определения (Document Type Definition) и схемы данных (Semantic Schema). В отличие от SGML, определение DTD- правил в XML не является необходимостью, и это обстоятельство позволяет нам создавать любые XML- документы, не ломая пока голову над весьма непростым синтаксисом DTD.

Конструкции языка XML

Содержимое XML- документа представляет собой набор элементов, секций CDATA, директив анализатора, комментариев, спецсимволов, текстовых данных. Рассмотрим каждый из них подробней.

Элементы данных

Элемент - это структурная единица XML- документа. Заключая слово rose в в тэги <flower> </flower>, мы определяем непустой элемент, называемый <flower>, содержимым которого является rose. В общем случае в качестве содержимого элементов могут выступать как просто какой-то текст, так и другие, вложенные, элементы документа, секции CDATA, инструкции по обработке, комментарии, - т.е. практически любые части XML- документа.

Любой непустой элемент должен состоять из начального, конечного тэгов и данных, между ними заключенных. Например, следующие фрагменты будут являться элементами:

<flower>rose</flower>

<city>Vladivostok</city>

а эти - нет:

<rose>

<flower>

rose

Набором всех элементов, содержащихся в документе, задается его структура, и определяются все иерархическое соотношения. Плоская модель данных превращается с использованием элементов в сложную иерархическую систему с множеством возможных связей между элементами. Например, в следующем примере мы описываем месторасположение Владивостокских университетов (указываем, что Дальневосточный Государственный Университет расположен в городе Владивостоке, который, в свою очередь, находится в России), используя для этого вложенность элементов XML:

<country id="Russia">

<cities-list>

<city>

<title>Vladivostok</title>

<state>Far East</state>

<universities-list>

<university id="2">

<title>Дальневосточный Государственный Университет</title>

<noprivate/>

<address URL="www.dvgu.ru"/>

<description>очень хороший университет</description>

</university>

<university id="2">

<title>Дальневосточный Государственный Технический Университет</title>

<noprivate/>

<address URL="www.dvgtu.ru"/>

<description>тоже не плохой</description>

</university>

</universities-list>

</city>

</cities-list>

</country>

Производя в последствии поиск в этом документе, программа клиента будет опираться на информацию, заложенную в его структуру - используя элементы документа. Т.е. если, например, требуется найти нужный университет в нужном городе, используя приведенный фрагмент документа, то необходимо будет просмотреть содержимое конкретного элемента <university>, находящегося внутри конкретного элемента <city>. Поиск при этом, естественно, будет гораздо более эффективен, чем нахождение нужной последовательности по всему документу.

В XML документе, как правило, определяется хотя бы один элемент, называемый корневым и с него программы-анализаторы начинают просмотр документа. В приведенном примере этим элементом является <country>

В некоторых случаях тэги могут изменять и уточнять семантику тех или иных фрагментов документа, по разному определяя одну и ту же информацию и тем самым предоставляя приложению-анализатору этого документа сведения о контексте использования описываемых данных. Например, прочитав фрагмент <city>Holliwood</city> мы можем догадаться, что речь в этой части документа идет о городе, а вот во фрагменте <restaurant>Holliwood</restaurant> - о забегаловке.

В случае, если элемент не имеет содержимого, т.е. нет данных, которые он должен определять, он называется пустым. Примером пустых элементов в HTML могут служить такие тэги HTML, как <br>, <hr>, <img>;. Необходимо только помнить, что начальный и конечные тэги пустого элемента как бы объединяется в один, и надо обязательно ставить косую черту перед закрывающей угловой скобкой (например, <empty/>;).

Комментарии

Комментариями является любая область данных, заключенная между последовательностями символов <!-- и --> Комментарии пропускаются анализатором и поэтому при разборе структуры документа в качестве значащей информации не рассматриваются.

Атрибуты

Если при определении элементов необходимо задать какие-либо параметры, уточняющие его характеристики, то имеется возможность использовать атрибуты элемента. Атрибут - это пара "название" = "значение", которую надо задавать при определении элемента в начальном тэге. Пример:

<color RGB="true">#ff08ff</color>

<color RGB="false">white</color>

или

<author id=0>Name</author>

Примером использования атрибутов в HTML является описание элемента <font>:

<font color=”white” name=”Arial”>Black</font>

Специальные символы

Для того, чтобы включить в документ символ, используемый для определения каких-либо конструкций языка (например, символ угловой скобки) и не вызвать при этом ошибок в процессе разбора такого документа, нужно использовать его специальный символьный либо числовой идентификатор. Например, &lt; , &gt; &quot; или &#036; (десятичная форма записи), &#x1a (шестнадцатеричная) и т.д. Строковые обозначения спецсимволов могут определяться в XML документе при помощи компонентов (entity).

Директивы анализатора

Инструкции, предназначенные для анализаторов языка, описываются в XML документе при помощи специальных тэгов - <? и ?>;. Программа клиента использует эти инструкции для управления процессом разбора документа. Наиболее часто инструкции используются при определении типа документа (например, <? Xml version=”1.0”?>) или создании пространства имен.

CDATA

Чтобы задать область документа, которую при разборе анализатор будет рассматривать как простой текст, игнорируя любые инструкции и специальные символы, но, в отличии от комментариев, иметь возможность использовать их в приложении, необходимо использовать тэги <![CDATA] и ]]>. Внутри этого блока можно помещать любую информацию, которая может понадобится программе- клиенту для выполнения каких-либо действий (в область CDATA, можно помещать, например, инструкции JavaScript). Естественно, надо следить за тем, чтобы в области, ограниченной этими тэгами не было последовательности символов ]].

Documents type definitions (dtd)

В XML- документах DTD определяет набор действительных элементов, идентифицирует элементы, которые могут находиться в других элементах, и определяет действительные атрибуты для каждого из них. Синтаксис DTD весьма своеобразен и от автора-разработчика требуются дополнительные усилия при создании таких документов (сложность DTD является одной из причин того, что использование SGML, требующего определение DTD для любого документа, не получило столь широкого распространения как, например, HTML). Как уже отмечалось, в XML использовать DTD не обязательно - документы, созданные без этих правил, будут правильно обрабатываться программой-анализатором, если они удовлетворяют основным требованиям синтаксиса XML. Однако контроль за типами элементов и корректностью отношений между ними в этом случае будет полностью возлагаться на автора документа. До тех пор, пока грамматика нашего нового языка не описана, его сможем использовать только мы, и для этого мы будем вынуждены применять специально разработанное программное обеспечение, а не универсальные программы-анализаторы.

В DTD для XML используются следующие типы правил: правила для элементов и их атрибутов, описания категорий (макроопределений), описание форматов бинарных данных. Все они описывают основные конструкции языка - элементы, атрибуты, символьные константы внешние файлы бинарных данных.

Для того, чтобы использовать DTD в нашем документе, мы можем или описать его во внешнем файле и при описании DTD просто указать ссылку на этот файл или же непосредственно внутри самого документа выделить область, в которой определить нужные правила. В первом случае в документе указывается имя файла, содержащего DTD- описания:

<?xml version="1.0" standalone="yes" ?>

<! DOCTYPE journal SYSTEM "journal.dtd">

...

Внутри же документа DTD- декларации включаются следующим образом:

...

<! DOCTYPE journal [

<!ELEMENT journal (contacts, issues, authors)>

...

]>

...

В том случае, если используются одновременно внутренние и внешние описания, то программой-анализатором будут сначала рассматриваться внутренние, т.е. их приоритет выше. При проверке документа XML- процессор в первую очередь ищет DTD внутри документа. Если правила внутри документа не определены и не задан атрибут standalone ="yes" , то программа загрузит указанный внешний файл и правила, находящиеся в нем, будут считаны оттуда. Если же атрибут standalone имеет значение "yes", то использование внешних DTD описаний будет запрещено.

Определение элемента

Элемент в DTD определяется с помощью дескриптора !ELEMENT, в котором указывается название элемента и структура его содержимого.

Например, для элемента <flower> можно определить следующее правило:

<!ELEMENT flower PCDATA>

Ключевое слово ELEMENT указывает, что данной инструкцией будет описываться элемент XML. Внутри этой инструкции задается название элемента (flower) и тип его содержимого.

В определении элемента мы указываем сначала название элемента (flower), а затем его модель содержимого - определяем, какие другие элементы или типы данных могут встречаться внутри него. В данном случае содержимое элемента flower будет определяться при помощи специального маркера PCDATA ( что означает parseable character data - любая информация, с которой может работать программа-анализатор). Существует еще две инструкции, определяющие тип содержимого: EMPTY,ANY. Первая указывает на то, что элемент должен быть пустым (например, <red/>), вторая - на то, что содержимое элемента специально не описывается.

Последовательность дочерних для текущего элемента объектов задается в виде списка разделенных запятыми названий элементов. При этом для того, чтобы указать количество повторений включений этих элементов могут использоваться символы +,*, ? :

<!ELEMENT issue (title, author+, table-of-contents?)>

В этом примере указывается, что внутри элемента <issue> должны быть определены элементы title, author и table-of-contents, причем элемент title является обязательным элементом и может встречаться лишь однажды, элемент author может встречаться несколько раз, а элемент table-of-contents является опциональным, т.е. может отсутствовать. В том случае, если существует несколько возможных вариантов содержимого определяемого элемента, их следует разделять при помощи символа "|" :

<!ELEMENT flower (PCDATA | title )*>

Символ * в этом примере указывает на то, что определяемая последовательность внутренних элементов может быть повторена несколько раз или же совсем не использоваться.

Если в определении элемента указывается "смешанное" содержимое, т.е. текстовые данные или набор элементов, то необходимо сначала указать PCDATA, а затем разделенный символом "|" список элементов.

Пример корректного XML- документа:

<?xml version="1.0"?>

<! DOCTYPE journal [

<!ELEMENT contacts (address, tel+, email?)>

<!ELEMENT address (street, appt)>

<!ELEMENT street PCDATA>

<!ELEMENT appt (PCDATA | EMPTY)*>

<!ELEMENT tel PCDATA>

<!ELEMENT email PCDATA>

]>

...

<contacts>

<address>

<street>Marks avenue</street>

<appt id="4">

</address>

<tel>12-12-12</tel>

<tel>46-23-62</tel>

<email>info@j.com</email>

</contacts>

Определение атрибутов

Списки атрибутов элемента определяются с помощью ключевого слова !ATTLIST. Внутри него задаются названия атрибутов, типы их значений и дополнительные параметры. Например, для элемента <article> могут быть определены следующие атрибуты:

<!ATTLIST article

id ID #REQUIRED

about CDATA #IMPLIED

type (actual | review | teach ) 'actual' ''

>

В данном примере для элемента article определяются три атрибута: id, about и type, которые имеют типы ID (идентификатор), CDATA и список возможных значений соответственно. Всего существует шесть возможных типов значений атрибута:

· CDATA - содержимым документа могут быть любые символьные данные

· ID - определяет уникальный идентификатор элемента в документе

· IDREF ( IDREFS )- указывает, что значением атрибута должно выступать название (или несколько таких названий, разделенных пробелами во втором случае) уникального идентификатора определенного в этом документе элемента

· ENTITY ( ENTITIES) - значение атрибута должно быть названием (или списком названий, если используется ENTITIES) компонента (макроопределения), определенного в документе

· NMTOKEN (NMTOKENS) - содержимым элемента может быть только одно отдельное слово (т.е. этот параметр является ограниченным вариантом CDATA)

· Список допустимых значений - определяется список значений, которые может иметь данный атрибут.

Также в определении атрибута можно использовать следующие параметры:

· #REQUIRED - определяет обязательный атрибут, который должен быть задан во всех элементах данного типа

· #IMPLIED - атрибут не является обязательным

· #FIXED "значение" - указывает, что атрибут должен иметь только указанное значение, однако само определение атрибута не является обязательным, но в процессе разбора его значение в любом случае будет передано программе-анализатору

· Значение - задает значение атрибута по умолчанию

Определение компонентов (макроопределений)

Компонент (entity) представляет собой определения, содержимое которых может быть повторно использовано в документе . В других языках программирования подобные элементы называются макроопределениями. Создаются DTD- компоненты при помощи инструкции !ENTITY:

<!ENTITY hello ' Мы рады приветствовать Вас!' >

Программа-анализатор, просматривая в первую очередь содержимое области DTD- определений, обработает эту инструкцию и при дальнейшем разборе документа будет использовать содержимое DTD- компонента в том месте, где будет встречаться его название. Т.е. теперь в документе мы можем использовать выражение &hello; , которое будет заменено на строчку "Мы рады приветствовать Вас"

В общем случае, внутри DTD можно задать три типа макроопределений:

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

В XML существует пять предустановленных внутренних символьных констант:

· &lt; - символ "<"

· &gt; - символ ">"

· &amp; - символ "&"

· &apos; - символ апострофа "&apos;"

· &quot; - символ двойной кавычки """

Внешние макроопределения - указывают на содержимое внешнего файла, причем этим содержимым могут быть как текстовые, так и двоичные данные. В первом случае в месте использования макроса будут вставлены текстовые строки, во втором - бинарные данные, которые анализатором не рассматриваются и используются внешними программами

<!ENTITY logotype SYSTEM "/image.gif" NDATA GIF87A>

Макроопределения правил - макроопределения параметров могут использоваться только внутри области DTD и обозначаются специальным символом %, вставляемым перед названием макроса. При этом содержимое компонента будет помещено непосредственно в текст DTD- правила

Например, для следующего фрагмента документа:

<!ELEMENT name (PCDATA)>

<!ELEMENT title (PCDATA | name)*>

<!ELEMENT author (PCDATA | name)*>

<!ELEMENT article (title, author)*>

<!ELEMENT book (title, author)*>

<!ELEMENT bookstore (book | article)*>

<!ELEMENT bookshelf (book | article)*>

можно использовать более короткую форму записи:

<!ELEMENT name (PCDATA)>

<! ENTITY %names 'PCDATA | name'>

<!ELEMENT article (%names;)*>

<!ELEMENT book (%names;)*>

<!ENTITY %content 'book | article'>

<!ELEMENT bookstore (%content;)*>

<!ELEMENT bookshelf (%content;)*>

Макроопределения часто используются для описания параметров в правилах атрибутов. В этом случае появляется возможность использовать одинаковые определения атрибутов для различных элементов:

<!ENTITY %itemattr 'id ID #IMPLIED src CDATA'>

<!ENTITY %bookattr "ISDN ID #IMPLIED type CDATA'>

<!ENTITY %artattr " size CDATA'>

<!ELEMENT book (title, author,content)*>

<!ATTLIST book %itemattr %bookattr;>

<!ELEMENT article (title, author, content)*>

<!ATTLIST article %itemattr %artattr;>

Типизация данных

Довольно часто при создании XML- элемента разработчику требуется определить, данные какого типа могут использоваться в качестве его содержимого. Т.е. если мы определяем элемент <last-modified>10.10.98</last-modified>, то хотим быть уверенными, что в документе в этом месте будет находиться строка, представляющая собой дату, а не число или произвольную последовательность символов. Используя типизацию данных, можно создавать элементы, значения которых могут использоваться, например, в качестве параметров SQL- запросов. Программа клиент в этом случае должна знать, к какому типу данных относится текущее значение элемента и в случае соответствия формирует SQL-запрос.

Если в качестве программы на стороне клиента используется верифицирующий XML-процессор, то информацию о типе можно передавать при помощи специально созданного для этого атрибута элемента, имеющего соответствующее DTD- определение. В процессе разбора программа-анализатор передаст значение этого атрибута клиентскому приложению, которое сможет использовать эту информацию должным образом. Например, чтобы указать, что содержимое элемента должно быть длинным целым, можно использовать следующее DTD- определение:

<!ELEMENT counter (PCDATA)>

<!ATTLIST counter data_long CDATA #FIXED "LONG">

Задав атрибуту значение по умолчанию LONG и определив его как FIXED, мы позволили тем самым программе-клиенту получить необходимую информацию о типе содержимого данного элемента, и теперь она может самостоятельно определить соответствие типа этого содержимого указанному в DTD- определении .

Схемы данных

Схемы данных (Schemas) являются альтернативным способом создания правил построения XML-документов. По сравнению с DTD, схемы обладают более мощными средствами для определения сложных структур данных, обеспечивают более понятный способ описания грамматики языка, способны легко модернизироваться и расширяться. Безусловным достоинством схем является также то, что они позволяют описывать правила для XML- документа средствами самого же XML.

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

Мы размечаем документ при помощи специальных элементов, выполняющих в схемах роль инструкций. Эти инструкции составляют набор правил, используя которые, программа-клиент будет делать вывод о том, корректен документ или нет. Схема данных, например, может выглядеть следующем образом:

<schema id="OurSchema">

<elementType id="#title">

<string/>

</elementType>

<elementType id="photo">

<element type="#title">

<attribute name="src"/>

</elementType>

<elementType id="gallery">

<element type="#photo">

</elementType>

</schema>

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

<gallery>

<photo id="1"><title>My computer</title></photo>

<photo id="2"><title>My family</title></photo>

<photo id="3"><title>My dog</title></photo>

</gallery>

, а некорректным этот:

<gallery>

<photo id="1"/>

<photo index="2"><title>My family</title></photo>

<photo index="3"><title> My dog </title><dogname>Sharik</dogname></photo>

</gallery>

Все конструкции языка схем описываются правилами "XML DTD for XML-Data-Schema". Этот документ вы можете найти среди другой официальной документации, доступной на сервере W3 - консорциума.