Экспериментальные значения поля 'Content-Type'

Значение типа, начинающееся с "X-", считается частным, предназначенным для использования по договоренности между двумя или более почтовыми системами. Публично определенные (регестрированные) значения никогда не должны начинаться с префикса "X-".

В общем, использование X-типов верхнего уровня не рекомендуется. Производители почтового ПО должны по возможности обходиться использованием X-подтипов для предопределенных типов. Во многих случаях использование экспериментального подтипа более приемлимо, нежели типа верхнего уровня.

Все определенные на сегодняшний день типы и подтипы

ТИППОДТИП

text	plain
	richtext
	enriched
	tab-separated-values
multipart	mixed
	alternative
	digest
	parallel
	appledouble
	header-set
message	rfc822
	partial
	external-body
	news
application	octet-stream
	postscript
	oda
	atomicmail
	andrew-inset
	slate
	wita
	dec-dx
	dca-rft
	activemessage
	rtf
	applefile
	mac-binhex40
	news-message-id
	news-transmission
	wordperfect5.1
	pdf
	zip
	macwriteii
	msword
	remote-printing
image	jpeg
	gif
	ief
	tiff
audio	basic
video	mpeg
	quicktime

Значения полей Content-Type и subtype, а также другие параметры заголовка являются чувствительными к регистру букв, если только не оговорены исключения для конкретного значения параметра.

Электронная доставка отчетов

По оценкам Gardner Group, в среднем каждый документ копируется 9–11 раз. Рассылка и доставка твердых копий— это довольно трудоемкая процедура, включающая в себя отправку факсов и электронных писем, либо доставку вручную. Эта проблема практически полностью снимается при использовании электронных отчетов: снижается не только потребление бумаги, но и прочие расходы и, главное, существенно сокращается время выполнения этой работы.

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

Установка графического терминала и возврат к текстовому терминалу:

Автоматический переход к графическому терминалу осуществляется при вызове программы, которая выполняет графические команды терминала Textronix 4014.

По Ctrl+Home происходит установка/очистка графического терминала.

Вызов на экран последнего графического образа (осуществляется через графическое меню) приводит к установке графического терминала.

По Home происходит переход обратно к текстовому терминалу.

По Alt+R отовсюду осуществляется переустановка терминала VT100.

Как проверить

Ну например : test1.pl - работает при помощи perl.exe и выводит на экран фразу "Hello, Perl !".

print "Content-type: text/html\n\n"; print "<HTML>"; print "<BODY>"; print ("Hello, Perl !"); print "</BODY>"; print "</HTML>";

А вот test2.plx использует perlis.dll и пишет на экране "Здравствуй, ПЕРЛ !". Обратите внимание : начальная строчка здесь другая, чем в test1.pl - именно так требуется для perlis.dll.

print "HTTP/1.0 200 OK \r\n"; print << "END"; Content-Type text/html

И наконец, test3.stm выдает на экран ваш IP-адрес используя скрипт test3.pl и SSI.

<body bgcolor="#FFFFFF" link="#000080" vlink="#660033"> <center> <font size=4 color=teal>Ваш IP-адрес</font> <font size=5 color=navy> </font> </center>

</body> </html>

А соответствующий скрипт test3.pl состоит всего из одной строки :

print $ENV{'REMOTE_ADDR'};

Как устанавливать

а) Выбираем директорию под файлы PERL, например C:\PERL - ни в коем случае не внутри директории web, а то получим большую дыру в системе безопасности.

в) Разархивируем скачанные архивы в выбранную директорию ( например, при помощи WinZip - важно, чтобы длинные имена файлов сохранились).

c) Устанавливаем модуль "Perl for Win32" : в возникшей директории BIN находим и запускаем perlw32-install.bat. Соглашаемся со всем, что предлагается.

d) Устанавливаем модуль "Perl for ISAPI" : в возникшей директории BIN находим и запускаем perlis-install.bat. Соглашаемся со всем, что предлагается, НО : расширение под файлы, которые система будет ассоциировать с perlis.dll лучше сменить с предлагаемого .PL на .PLX, или что нибуть в этом роде : по традиции .PL обычно резервируется под файлы, обрабатываемые perl.exe - главным файлом "Perl for Win32".

e) Еще одно действие понадобится для тех случаев, когда желательно непосредственно применять perl.exe - главный файл "Perl for Win32". ( Напомним, что теоретически perlis.dll делает все то же самое, что и perl.exe, но только быстрее. Практически, однако, нам не удалось заставить его корректно работать с SSI- Server Side Include. А это ключевой элемент для счетчиков или , скажем, вставления часов на страницу. Есть и другие тонкости. Так что пожалуй, лучше сразу сделать - ну хотя бы для того, чтобы реально сравнить по скорости perl.exe и perlis.dll. ) Итак, нужно добавить в Registry запись, ассоциирующую файлы с расширением .PL с perl.exe. Любопытно : то же для perlis.dll инсталляционная программа сделала автоматически, а для perl.exe - нет.

Вызываем winnt/system32/regedt32 и находим HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services \W3SVC\Parameters\ScriptMap

Там уже должна быть запись

.plx:REG_SZ: c:\perl\bin\PerlIS.dll

( предполагается, что директория, выбранная в пункте а) - c:\perl ). После этой записи надо добавить

.pl:REG_SZ: c:\perl\bin\Perl.exe %s %s

Любопытно, что вот про эти %s %s - в FAQ от Evangelo Prodromou - ни слова, а без них все как настоящее, но не работает.

f) Если потребуется SSI ( а наверняка потребуется ), то ровно в том же месте Registry, прямо под двумя предыдущими записями делаем еще одну :

.stm:REG_SZ: C:\WINNT\system32\inetsrv\Ssinc.dll

-мы ассоциируем файлы с расширением .stm с отвечающим за SSI .dll. Это .dll из комплекта IIS и никак с perl не связан. Расширение можно, видимо, при желании изменить, но это не может быть .htm . Разумеется, если вы при инсталляции выбрали другое название для директории с файлами IIS - его и проставьте.

g) Теперь кладем наши скрипты в какую-нибуть директорию внутри web и при помощи Microsoft Internet Service Manager ( Inetmngr ) прописываем ее как директорию web с правами Access : Read Execute. Те же права нужны кстати и для SSI.

h) Все. Перегружаем NT ( именно NT перегружаем, а не только web - иначе записи в Registry не вступят в силу )

КОЛЛЕКТИВНАЯ МУДРОСТЬ

Отчасти BizTalk представляет собой не что иное, как общественный сервер Web (http://www.biztalk.org), где публикуются все схемы, предложенные для использования в различных отраслях. Маркус Шмидт, менеджер по работе с компаниями, специализирующимися в области поставок, говорит, что Microsoft и другие члены Инициативной группы BizTalk работают над рекомендациями и тегами XML для придания некоторого однообразия использованию XML в бизнесе. Однако BizTalk не ставит своей целью объединить все отрасли в попытке составить одну гигантскую схему для всех используемых в каком бы то ни было бизнесе данных. «Мы очень хорошо понимаем, что никогда не сможем заставить различные отрасли прийти к согласию даже по поводу фундаментальных вещей, например в отношении определения заказчика, так как каждой из них требуется своя информация о заказчике. Мы пытаемся добиться того, чтобы, когда производитель решит составить свою собственную схему, он имел как можно более высокие шансы, что его схема будет совместима с чьей-либо еще, если он станет следовать нашим рекомендациям и если другие будут иметь возможность без труда получить его схему, чтобы они могли установить соответствие между своей и его схемой».

В целом, как объясняет Шмидт, BizTalk состоит из трех отдельных элементов. Во-первых, это хранилище на сервере Web вместе с рекомендациями и тегами XML, используемыми для добавления новых схем в хранилище. Во-вторых, это разработка программного продукта, сервера BizTalk. И в-третьих, это будут интерактивные услуги на базе технологии BizTalk.

определяют массив названий групп,

Строки 3-5: подключение модулей
Строка 7: Адрес news-сервера можно конечно же поменять.
Строки 12- 22 определяют массив названий групп, в длинной форме - для сервера и в короткой - для человека. Длинное имя можно получить, например, так - $groups[2][0], а короткое - $groups[2][1]
В строке 24 создается CGI-объект $Q. Входные данные скрипт может получать из командной строки, через переменную окружения и из стандартного потока ввода.
Строка 25 позволяет получитьURL скрипта, который используется в дальнейшем.
В 27 строке проверяется входной параметр 'group'. И если его нет - то выводится полный список групп. Строки 28-44 создают страничку со списком доступных групп на основе массива @groups 28-29 строки создают переменную $links, содержащую ссылки на группы в виде:
<p><a href="SOMEWHERE?group=clari.living.comics.doonesbury">Doonesbury</a> Где SOMEWHERE - это как раз URL скрипта.
Строки с 32 по 40 выводят результат - заголовок, начало HTML-документа, список ссылок и конец HTML-документа. Конструкция @{[thing]} - это вывод 'thing' в списковом контексте. Можно было вместо этого просто разбить оператор print на несколько операторов print.
Строка 46: проверка на наличие входного параметра article.
Строки с 47 по 65 выводят список сообщений в выбранной группе.
Строка 47: установление соединения с news-сервером (порт 119 - стандартный)
Строки с 48 по 51: вывод тем всех сообщений в данной конференции. Выражение в строке 48 возвращает массив строк, где символом табуляции разделены номер и тема сообщения. 49 строка разбивает строки, а 50тая - создает строку со списком уже в HTML-виде, где на каждое сообщение - своя ссылка:
<p><a href="SOMEWHERE?group=clari.living.comics.doonesbury&article=123">Doonesbury 950101</a>
Строки 52-60: вывод результатов
Строка 69 начинает часть скрипта, которая непосредственно выдает картинки, содержащиеся в отдельных сообщениях. Снова устанавливается соединение с news-сервером, и забирается уже конкретное сообщение.
Строка 71: сообщение укладывается в массив @art
Строка 72: так как важна только та часть сообщения, которая начинается с Content-type, то все остальные строки можно выкинуть. При этом сохраняется тип картинки (строка 73).
Строки 74-75: Пустая строка после Content-type пропускается
Строка 76: непосредственно декодирование из base64
Строки 77-78: вывод картинки браузеру

Концепция проекта

При разработке проекта ebXML использовались следующие основные принципы:

простое, единое и повсеместное использование ebXML в электронном бизнесе; использование спецификаций XML в максимально возможных пределах; обеспечение открытыми стандартами электронной торговли: B2B (business to business) и ВС (business to Customer); объединение структуры и содержания компонентов расходящихся XML инициатив в единый XML бизнес стандарт; Минимизация затрат при обмене приложение-приложение; обеспечение мультиязыковой поддержки; учитывание национальных и международных правил торговли; учитывание традициональных принципов EDI на основе стандарта UN/EDIFACT.

Рабочая группа создания глобального электронного рынка - ebXML работает в следующих направлениях, которые выделены как самостоятельные проекты:

Разработка общей методологии и основных компонентов; Разработка спецификаций технической архитектуры; Разработка спецификаций для Репоситориев (Центр электронного бизнеса) Разработка спецификаций пакетов и маршрутизации; Моделирование бизнесс процесов и создание службы сообщений;

На рис.1 представлено взаимодействие основных компонентов ebXML при осуществлении бизнес-транзакций.

Рис 1.

Некая Компания Х (Interprise Systems) ведет электронный обмен с другой Компанией Y через Центр электронного бизнеса - Репоситорий (Repository). Электронный бизнес осуществляется путем обмена между компаниями электронными бизнесс-документами.

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

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

На рис.2 представлен один из вариантов обмена Электронными документами для компаний X и Y.

Рис 2.

Конфигурация

Стандартная конфигурация NCSA Telnet включает 3 необходимые файла:

TELNET.BAT - Файл запуска. Содержит пути к остальным двум файлам.

TELBIN.EXE - Собственно исполнимый файл NCSA Telnet.

CONFIG.TEL - Файл конфигурации, к которому обращается Telbin.exe. Он содержит всю информацию о сети.

Файл конфигурации программы Config.tel может быть переименован следующим образом. В файле Autoexec.bat должна быть помещена строка типа:

SET CONFIG.TEL=C:\TELNET\TELNET.CFG

где, Telnet.cfg - новое имя файла конфигурации. \break \break Пример строки запуска в файле Telnet.bat:

c:\telnet\telbin -h c:\telnet\config.tel %1 %2 ...

1 2 3 4

1 - Указывается путь к исполняемому файлу

2 - Опция, сообщающая, что дальше будет путь к файлу конфигурации

3 - Путь к файлу конфигурации

4 - Параметрами .bat файла должны быть машины с которыми будет устанавливаться связь.

Кратко о PERL-модулях от Active State

Active State - на сегодняшний день основной поставщик модулей PERL для IIS. Для начала вполне достаточно того, что можно скачать у нее. ( Впрочем, если вас интересуют именно все возможные варианты или история вопроса - читайте указанный выше FAQ ). Кстати, в этом FAQ Active State называется свом старым именем - Active Ware.

Cушествует не один, а несколько модулей от Active State для разных аспектов поддержки PERL для IIS. Есть модуль "Perl for Win32" - это exe-файл,буквальный аналог соответствующего исполняемого perl-модуля под Unix. Однако специфика архитектуры Windows NT такова, что написанный специально под нее модуль- DLL, выполняя то же самое, будет работать быстрее ( не будем здесь вдаваться в объяснения - почему ). Этот модуль-DLL носит название "Perl for ISAPI". Двух указанных модулей - "Perl for Win32" и "Perl for ISAPI" хватает для решения большинства простейших задач с применением PERL. Их установку и использование мы и рассмотрим в данной заметке. ( Для многих задач хватило бы и одного "Perl for ISAPI", но технически его нельзя установить без "Perl for Win32" ).

А еще есть модуль "PerlScript", который глубже интегрирован в IIS - модуль для ASP ( Active Server Pages, особенность IIS начиная с IIS3, использующая Microsoft Active X.) Еще есть модуль "PerlEx" для ускорения работы CGI-скриптов ( еще раз ускорения, но уже за деньги) . И, наконец, графический Perl Debugger - тоже не бесплатный, бесплатна только версия на неделю.

Листинг:

=1= #!/usr/bin/perl -w =2= use strict; =3= $|++; =4= =5= ## config =6= =7= my @URL = qw(http://www.stonehenge.Xcom/); =8= =9= sub OK_TO_FOLLOW { =10= my $uri = shift; # URI object, known to be http only =11= for ($uri->host) { =12= return 0 unless /\.stonehenge\.Xcom$/i; =13= } =14= for ($uri->query) { =15= return 0 if defined $_ and length; =16= } =17= for ($uri->path) { =18= return 0 if /^\/(cgi|fors|-)/; =19= return 0 if /col\d\d|index/; =20= return 0 if /Pictures/; =21= return 0 unless /(\.html?|\/)$/; =22= } =23= return 1; =24= } =25= =26= ## end config =27= =28= use WWW::Robot; =29= use LWP::UserAgent; =30= use CGI::Pretty qw(-no_debug :html); =31= use HTML::Entities; =32= =33= my %description; =34= my %keywords; =35= my %keyword_caps; =36= =37= my $robot = WWW::Robot->new =38= ( =39= NAME => 'MetaBot', =40= VERSION => '0.15', =41= EMAIL => 'merlyn@stonehenge.Xcom', =42= USERAGENT => LWP::UserAgent->new, =43= CHECK_MIME_TYPES => 0, =44= ## VERBOSE => 1, =45= ); =46= =47= $robot->env_proxy; =48= =49= $robot->addHook =50= ("follow-url-test" => sub { =51= my ($robot, $hook, $url) = @_; =52= return 0 unless $url->scheme eq 'http'; =53= OK_TO_FOLLOW($url); =54= }); =55= $robot->addHook =56= ("invoke-on-contents" => sub { =57= my ($robot, $hook, $url, $response, $structure) = @_; =58= my %meta = map { =59= my $header = $response->header("X-Meta-$_"); =60= defined $header ? ($_, $header) : (); =61= } qw(Description Keywords); =62= return unless %meta; =63= if (exists $meta{Description}) { =64= $_ = $meta{Description}; =65= tr/ \t\n/ /s; =66= $description{$url} = $_; =67= } =68= if (exists $meta{Keywords}) { =69= for (split /,/, $meta{Keywords}) { =70= s/^\s+//; =71= s/\s+$//; =72= $keywords{lc $_}{$url}++; =73= $keyword_caps{lc $_} = $_; =74= } =75= } =76= }); =77= $robot->run(@URL); =78= =79= my %seen_letter; =80= =81= print =82= table({ Cellspacing => 0, Cellpadding => 10, Border => 2 }, =83= do { =84= my %letters; =85= @letters{map /^([a-z])/, keys %keywords} = (); =86= %letters ? =87= Tr(td({Colspan => 3}, =88= p("Jump to:", =89= map a({Href => "#index_$_"}, uc $_), sort keys %letters))) =90= : 0; =91= }, =92= map { =93= my $key = $_; =94= my @value = =95= map { =96= my $url = $_; =97= my $text = exists $description{$url} ? =98= $description{$url} : "(no description provided)"; =99= =100= [a({Href => encode_entities($url)}, encode_entities($url)), =101= encode_entities($text), =102= ]; =103= } sort keys %{$keywords{$key}}; =104= my $key_text = $keyword_caps{$key}; =105= if ($key =~ /^([a-z])/ and not $seen_letter{$1}++ ) { =106= $key_text = a({ Name => "index_$1" }, $key_text); =107= } =108= =109= map { =110= Tr(($_ > 0 ? () : td({Rowspan => scalar @value}, $key_text)), =111= td($value[$_])); =112= } 0..$#value; =113= } sort keys %keywords =114= );

Литература

"Surge Lab Documentation. Developer's Guide"; Curl Corporation; Cambridge, Massachusetts; 2001

Литература

Extensible Markup Language 1.0 (Second Edition), W3C Recommendation (6 October 2000), . World Wide Web Consortium, . Schema, Parts 0, 1, and 2, W3C Recommendation (2 May 2001), , and . Path Language Version 1.0, W3C Recommendation (1999 16 November), . Transformation Version 1.0, W3C Recommendation (1999 16 November), . XML Query Working Group, . XQuery 1.0: An XML Query Language, W3C Working Draft (2002 16 August), . Query Requirements, W3C Working Draft (15 February 2001), . XQuery 1.0 and XPath 2.0 Data Model, W3C Working Draft (2002 16 August ), . XQuery 1.0 Formal Semantics, W3C Working Draft (2002 16 August), . XQuery 1.0 and XPath 2.0 Functions and Operators, W3C Working Draft (2002 16 August), . XMLQuery Use Cases, W3CWorking Draft (16 August 2002), . D. Chamberlin, J. Robie, D. Florescu, "Quilt: An XML Query Language for Heterogeneous Data Sources", Lecture Notes in Computer Science, Springer-Verlag (2000 December) T. Atwood, D. Barry, J. Duhl, J. Eastman, G. Ferran, D. Jordan, M. Loomis, D. Wade, The Object Database Standard: ODMG-93, Release 1.2, R. G. C. Catell, Editor, Morgan Kaufmann Publishers, San Francisco, CA (1996). Information Technology-Database Language SQL, Standard No. ISO/IEC 9075, International Organization for Standardization (1999); New York. J. Robie, J. Lapp, D. Schach, XML Query Language, . A. Deutsch, M. Fernandez, D. Florescu, A. Levy, D. Suciu, A Query Language for XML, . S. Abiteboul, D. Quass, J. McHugh, J. Widom, J. Wiener, "The Lorel Query Language for Semistructured Data", International Journal on Digital Libraries 1, No. 1, 68-88 (1997 April), . Namespaces in XML, W3C Recommendation (1999 14 January), . XML Path Language 2.0, W3C Working Draft (2001 20 December), .

Дон Чемберлин - сотрудник исследовательского центра IBM Almaden Research Center; известен как один из разработчиков языка SQL и автор двух книг по реляционным базам данных. Сейчас деятельность Чемберлина связана с технологиями реляционных баз данных, обработкой документов и XML. Он является представителем IBM в рабочей группе W3C XML Query Working Group и редактором спецификации XQuery.

Don Chamberlin, Xquery: An XML query language. IBM Systems Journal, Vol. 41, No. 4, 2002. Copyright 2002, International Business Machines Corporation. All rights reserved. Reprinted with permission.

Local или Remote echo mode

При работе в сессии существуют два Эхо режима: Режим локального (Local, Line) эха или Режим удаленного (Remote, Character) эха. При Remote echo mode каждый набранный символ сразу передается на удаленную машину и затем отображается на экране сессии. Такой режим является не очень удобным, если время передачи велико. В этом случае используют Local echo mode, при котором строка набираемых символов запоминается (отображаясь на экране) в буфере локальной машины и по ENTER целиком передается на удаленную машину.

При Local, Line echo mode:

Ctrl-U - Уничтожает локальный буфер

BackSpace (Ctrl-H) - Уничтожает последний набранный символ в лок. буфере

Tab (Ctrl-I), все управляющие ASCII символы и символы, начинающиеся с ^ - Посылают содержимое локального буфера на удаленную машину вместе с этим символом.

Alt - [символ] - Не действуют (отображаются) в Local echo mode.

Remote echo mode используется при полноэкранном редактировании.

Существуют некоторые особенности передачи кодов некоторых клавиш, связанные с обеспечением совместимости.

Логическая структура документа

DTD HTML определяет правила построения HTML-документа, синтаксис элементов разметки и их возможное взаимное расположение. Если взглянуть на документ как на множество объектов, которые ассоциируются с элементами разметки, то DTD будет задавать иерархию классов этих объектов.

Логическая структура документа определяет отношения объектов между собой. Существует, по крайней мере, две модели объектов документа: модель JavaScript и DOM. Первая поддерживается, с некоторыми оговорками, практически всеми наиболее популярными браузерами. Вторая только претендует на роль стандарта и должна в будущем поддерживаться всеми браузерами.

Отношения отдельных объектов между собой сводятся, главным образом, к отношениям типа "часть-целое", а структура документа представляет собой дерево. В роли остова выступает дерево блочных элементов разметки документа. Затем на этот остов накладываются строчные элементы и стили. Кроме того, у документа существует поддерево классов объектов документа, определяемое в DTD. Изменение свойств класса приводит к изменению свойств всех объектов данного класса (рис. 2).

Рис. 2. Логическая структура документа.

Следует отметить, что логическая структура на рис. 2 гораздо ближе к модели данных Internet Explore, чем к JavaScript. Тем не менее, IE поддерживает модель JavaScript за исключением слоев, а в новой версии Netscape Navigator обещана поддержка DOM, которая совпадает с моделью IE.

Машины, с которыми осуществляется связь

NCSA Telnet может осуществлять соединение только с компьютерами, которые имеют IP адрес. Под host1, host2 .. в строке вызова Telnet понимает адреса (имена) машин в сети. Это может быть:

Любое имя, указанное в конфигурационном файле.

Если Telnet сконфигурирован с использованием основанного на доменах name-сервера, то любое имя с доменом может быть использовано.

Полный IP - адрес. (Например: 192.17.22.20)

Если машины в одной и той же Ethernet, то можно указать #, а за ним номер машины в локальной сети.

После IP адреса можно указать #, и затем, порт соединения.

Этот алгоритм разработан для представления

Этот алгоритм разработан для представления произвольных последовательностей байтов в форму, читаемую для человека. Кодирующий и декодирующий алгоритмы очень просты, но закодированные данные примерно на 33% больше, чем некодированные. этот метод идентичен тому, который используется в приложениях PEM (Privacy Enhanced Mail), описанной в RFC 1421 с одним отличием: base64 не приемлит встроенного "чистого" текста.

Base64 использует 65-символьный поднабор из US-ASCII, выделяя 6 бит на каждый печатный символ. (65-й символ "=" используется для обозначения функции спец. обработки).

ПРИМЕЧАНИЕ: этот поднабор имеет важное свойство: он идентичен всем версиям языковой кодировки ISO 646, включая US ASCII, а также всем версиям EBCDIC. Другие популярные механизмы кодирования (uuencode, base85 - часть уровня 2 PostScript) не разделяют этих свойств и поэтому не удовлетворяют требованиям переносимости для двоичных данных электронной почты.

Процесс кодирования преобразует 3 входных символа в виде 24-битной группы, обрабатывая их слева направо. Эти группы затем рассматриваются как 4 соединенные 6-битные группы, каждая из которых транслируется в одиночную цифру алфавита base64. При кодировании base64, входной поток байтов должен быть упорядочен старшими битами вперед.

Каждая 6-битная группа используется как индекс для массива 64-х печатных символов. Символ, на который указывает значение индекса, помещается в выходную строку. Эти символы выбраны так, чтобы быть универсально представимыми и исключают символы, имеющие специальное значение для SMTP-транспорта (".", CR, LF) и для синтаксиса вложенных тел MIME ("-"). Таблица 1: Алфавит Base64

Значение КодЗначение КодЗначениеКодЗначениеКод

0	A	17	R	34	i	51	z
1	B	18	S	35	j	52	0
2	C	19	T	36	k	53	1
3	D	20	U	37	l	54	2
4	E	21	V	38	m	55	3
5	F	22	W	39	n	56	4
6	G	23	X	40	o	57	5
7	H	24	Y	41	p	58	6
8	I	25	Z	42	q	59	7
9	J	26	a	43	r	60	8
10	K	27	b	44	s	61	9
11	L	28	c	45	t	62	+
12	M	29	d	46	u	63	/
13	N	30	e	47	v
14	O	31	f	48	w	=	(заполнитель)
15	P	32	g	49	x
16	Q	33	h	50	y

Выходной поток ( закодированные бфайты) должен иметь длину строк не более 76 символов. Все признаки перевода строки и другие символы, отсутствующие в таблице 1, должны быть проигнорированы декодером base64. Среди данных в Base64 символы, не перечисленные в табл. 1, переводы строки и т.п. должны говорить об ошибке передачи данных, и, соответственно, почтовая программа должна оповестить пользователя о ней.

Если в хвосте потока кодируемых данных осталось меньше, чем 24 бита, справа добавляются нулевые биты до образования целого числа 6-битных групп. А до конца 24-битной группы остается от 0 до 3-х недостающих 6-битных групп, вместо каждой из которых ставится символ-заполнитель '='. Поскольку весь входной поток представляет собой целое число 8-битных групп (т.е., просто байтных значений), то возможны лишь следующие случаи: (1) входной поток как раз оканчивается 24-битной группой. В таком случае, выходной поток будет оканчиваться четырьмя символами Base64 без символа '='; (2) хвост входного потока имеет длину 8 бит. Тогда в конце выходного кода быдут два символа Base64, с добавлением двух символов '='; (3) хвост входного потока имеет длину 16 бит. Тогда в конце выходного будут стоять три символа Base64 и один символ '='.

Т.к. символ '=' является хвостовым заполнителем, его появление в теле письма может означать только то, что конец данных достигнут. Но такой гарантии нет, если число переданных битов кратно 24.

Любые бессмысленные последовательности в коде Base64 вроде "=====" должны быть игнорированы.

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

Нет нужды экранировать вложенные тела внутри многочастного тела (multipart) при кодировании его в Base64, так как в коде Base64 отсутствует символ '-'.

Механизм конвертации "Quoted-Printable"

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

В Quoted-Printable байты должны быть рпедставлены в соответствии со следующими правилами:

ПРАВИЛО #1: (обычное 8-битное представление). Каждый байт, кроме тех, которые используются для обозначения конца строки, может быть представлен с помощью двух шестнадцатиричных цифр, предворяемых знаком "=". При написании шестнадцатиричных цифр с A по F должны использоваться заглавные буквы. Кроме тех случаев, когда нижеследующие правила позволяют альтернативное кодирование, данное правило является обязательным.

ПРАВИЛО #2: (Буквенное представление). Байты с десятичным значением с 33 по 60 и с 62 по 126 МОГУТ быть представлены ASCII-символами, соответствующими этим значениям (с '!' по '<' и с '>' по '~').

ПРАВИЛО #3: (Пробелы): Байты со значениями 9 и 32 МОГУТ быть представлены как ASCII-символы "Табуляция" и "Пробел", но НЕ ДОЛЖНЫ быть представлены так в конце строки. Везде, где они представлены соответствующими ASCII-символами, за ними должен следовать символ, имеющий графическое изображение (печатный символ). В конце же строки символы табуляции и пробела должны быть представлены в соответствии с правилом #1, так как некоторые почтовые транспорты могут убирать пробелы в конце строки.

ПРАВИЛО #4: (Конец строки): Конец строки в тексте письма должен быть представлен (в соответствии с RFC 822) последовательностью CRLF.

Так как в каноническом представлении текста не требуется визуального отображения символов конца строки, в Quoted-Printable не используется видимых символов для обозначения конца строки. Для представления бинарных данных более предпочтительной является кодировка base64.

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

ПРАВИЛО #5: (Мягкий конец строки): В соответствии с Quoted-Printable длина строки не должна превышать 76 символов. В противном случае используется 'мягкий' перевод строки, представимый знаком равенства. Например, если исходная строка имела вид: Now's the time for all folk to come to the aid of their country.

то в Quoted-Printable encoding он может быть представлена следующим образом: Now's the time = for all folk to come= to the aid of their country.

Это обеспечивает механизм восстановления исходной длины строки пользовательским почтовыи агентом.

Поскольку символ дефиса ("-") представляется в Quoted-Printable в обычном виде, особую осторожность нужно соблюдать при заключении тела в Quoted-Printable в многочастное письмо, чтобы удостовериться, что граница этого включения не проявляется нигде внутри этого включения (лучше всего выбрать обозначение границы в виде последовательности символов "=_", которая никогда не появляется в теле, закодированном в Quoted-Printable. См. определение многочастного письма далее.)

ЗАМЕЧАНИЕ: Quoted-Printable представляет собой нечто вроде компромисса между читабельностью и сохранностью при пересылке. Тела в Quoted-Printable будут надежно защищены при прохождении многих почтовых шлюзов, но могут быть не очень хорошо переданы через некоторые шлюзы, использующие трансляцию в EBCDIC. (Теоретически, EBCDIC-шлюз должен кодировать тело из quoted-printable в base64 и затем декодировать обратно, но таких шлюзов пока не существует).

Единственный способ добится действительно надежной транспортировки через EBCDIC-шлюз - экранировать ASCII-символы !"#$@[\]^`{|}~

в соответствии с правилом #1.

Так как данные в quoted-printable являются строчно-ориентированными, можно ожидать, что представление концов строки в Quoted-Printable будет изменено почтовым транспортом таким же образом, как и обычный текст может измениться при пересылке по Internet-почте между системами с разными соглашениями по представлению концов строки. Если подобные изменения могут нарушить целостность данных, то имеет смысл пользоваться кодировкой base64, а не Quoted-Printable.

Вниманию создателей ПО: Если двоичные данные пересылаются в Quoted-Printable, то надо соблюдать осторожность при кодировании символов CR и LF. В частности, последовательность CRLF должна быть представлена как "=0D=0A", в противном случае, если CRLF означает конец строки, то она может быть неверно интерпретирована в платформах с другими соглашениями по концу строки.

Синтаксис данных в quoted-printable описывается следующим образом: quoted-printable := ([*(простой текст / ПРОБЕЛ / ТАБУЛЯЦИЯ) простой текст] ["="] CRLF) ; Максимальная длина строки - 76 символов, включая CRLF простой текст := байт /<любой ASCII-символ "=", ПРОБЕЛ или ТАБУЛЯЦИЯ> ; символы, не перечисленные в приложении B к RFC 1521 как безопас- ; ные для почты, также не рекомендуются к использованию байт := "=" 2(ФИФРА / "A" / "B" / "C" / "D" / "E" / "F") ; байт используется для символов > 127, =, ПРОБЕЛ, или ТАБУЛЯЦИЯ, ; и рекомендуется для представления любых символов, не перечислен- ; ных в приложении B к RFC 1521 как безопасные для почты

Меню параметров NCSA Telnet

Все параметры работы NCSA Telnet обычно устанавливаются в файле конфигурации config.tel. Просмотреть некоторые параметры и/или изменить их не прерывая работу в NCSA Telnet можно через меню параметров, вызываемому по Alt+P. Например, это меню предлагает установить цвета для каждой сессии и имя Capture файла, одно для всех сессий. Вид меню параметров следующий: \hrule

Нормальный цвет символов (nfcolor)

Нормальный цвет фона (nbcolor)

Реверсный цвет символов (rfcolor)

Реверсный цвет фона (rbcolor)

Цвет подчеркивания символов(ufcolor)

Цвет подчеркивания фона (ubcolor)

** Local или Remote echo mode... (Line или Character echo mode

Backspace значение .................... Delete (Устанавливается, если возникают проблемы с удаленной машиной)

Имя сессии ............................ **&gt (Имя удаленной машины)

**Тип терминала ....................... VT102 и Textronix 4014 (обычно)

Перенос строк ............................ Wrapping ON

Output Mapping ........................... Mapping OFF \hrule Параметры, общие для всех сессий \hrule Имя Capture файла ....................... **&gt capfile

** Тип экрана (BIOS совместимость).. Direct to Screen (прямо на экран)

Передача файлов (FTP) ....................... Enabled (Разрешена)

Удаленное копирование (rcp) ............. Disabled (Не разрешено)

Часы ...................................................... Enabled (Установлены) \hrule

Microsoft + Internet = ActiveX

, "Мир Internet", ноябрь 1996 г.

В моей смерти прошу винить Билла Г.

(из сетевого юмора)

Программисты и дизайнеры World Wide Web не успели еще прийти в себя после сокрушающей лавины нововведений, обрушенной на их головы фирмой Netscape меньше года назад. Индустрия подключаемых модулей (plug-ins) для броузера Netscape Navigator едва-едва успела окрепнуть, а программисты-любители еще только вошли во вкус новых языков Java и JavaScript. В то же время поразительно единодушие, с которым именно этот набор технологий признавался единственно возможным фундаментом для построения интерактивного, динамичного и безопасного Интернета XXI века - века, когда нынешние ограничения пропускной способности каналов и мощности компьютеров уйдут наконец в прошлое.

Как вдруг... Постойте, но что же произошло? Чем объяснить появление и триумфальное шествие еще одного новшества в этой и без того перенаселенной и бурно развивающейся отрасли? Что представляет собой технология ActiveX, дебютировавшая вместе с версией 3.0 броузера Microsoft Internet Explorer? Новая ли это, быстропроходящая мода, очередная ли попытка корпорации Microsoft изобрести дудочку, под которую будет плясать весь Интернет, или действительно нечто, что изменит жизнь всех Web-дизайнеров?

Если быть предельно кратким, ActiveX - это старая добрая технология OLE (Object Linking and Embedding, "связывание и встраивание объектов"), появившаяся впервые вместе с Windows 3.1 еще в 1991 году. Сейчас Microsoft пытается приспособить OLE для наполнения WWW интерактивным содержимым, а тем самым - и для тесной, но максимально прозрачной для пользователя интеграции сетевых ресурсов с операционной системой Windows. Те, кого больше интересует мир UNIX, дальше могут не читать - ни OLE, ни ActiveX для UNIX пока не существует, и хотя Microsoft и собирается проталкивать свою новую технологию в этом направлении, никаких конкретных обещаний или тем более сроков не называется.

Как и OLE, ActiveX представляет собой довольно пестрый набор разнородных технологий, объединенных скорее общей идеологией, чем каким-то единым стандартом. Для начального ознакомления принято разделять букет ActiveX на три части - органы управления (ActiveX controls), сценарии (ActiveX scripts) и документы (ActiveX documents). Вероятно, опытного Web-дизайнера, уже знакомого с Java и JavaScript, в первую очередь заинтересуют органы управления ActiveX, которым и посвящена большая часть этой статьи.

Мифы и реальности XML

Сергей Кузнецов

ИСП РАН, Центр информационных технологий

Людям свойственно верить в философский камень. Вот-вот кто-то его изобретет, и вся жизнь изменится. Так происходит и в мире информационных технологий. Вспомним, например, краткую, но яркую историю Java-технологий. В 1995 г. мне довелось присутствовать на двухдневной конференции, организованной компанией Sun Microsystems специально для журналистов. Формально конференция посвящалась выпуску первого микропроцессора серии UltraSparc. Фактически большую часть времени заняло представление нового объектно-ориентированного языка Java. Тогда меня потрясло выступление Билла Джоя, который сказал, что создание этого языка является главным достижением в его жизни, и что наконец-то открываются реальные возможности организации и доступа в Internet мультимедийной информации. Наверное, все помнят, сколько сил и средств затратила Sun, чтобы убедить разработчиков программного обеспечения полностью перейти на использование языка Java.

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

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

Миф первый. XML полностью изменит жизнь в Internet, обеспечив, наконец, единое мировое информационное пространство.

Миф второй. XML станет единым общепринятым стандартом представления информации в системах электронного бизнеса (как B2C, так и B2B).

Миф третий. Основанные на XML системы баз данных за счет своей большей гибкости вытеснят реляционные и другие системы.

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

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

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

Миф второй (опровержение). Если первый миф свойственен несчастным пользователям Internet, то второй очень сильно раздувается за счет усилий отделов маркетинга производителей аппаратуры и программного обеспечения.

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

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

Миф третий (опровержение). Давайте вспомним, откуда есть пошли базы данных. А оттуда, что при наличии только файловых систем (с которых и началось управление данными во внешней памяти) структуру данных (бухгалтерских, банковских, систем резервирования и т.д.) приходилось поддерживать в прикладной программе. А если их больше одной? Как контролировать согласованность? Я ж не буду говорить про целостность данных, возможность многопользовательского доступа, транзакционное управление, журнализация изменений и восстановление после сбоев и т.д. Мифичность того, что базы данных, основанные на XML, вытеснят традиционные базы данных, для меня очевидна. Имеется масса прикладных областей, в которых нужны именно структурированные, а не полуструктурированные данные. Для них нужны и будут нужны традиционные базы данных со структурированной схемой.

Реальность состоит в том, что имеется множество информационных приложений, для которых данные не укладываются естественным образом в традиционные модели. Для них XML может быть весьма полезен. Но замечу, что при наличии нескольких коммерческих серверов XML-баз данных, ни в одном из них пока не решены в полном объеме те задачи, с решением которых успешно справляются традиционные СУБД.

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

В некотором смысле XML аналогичен языку ассемблера. Предположим, что нам требуется спроектировать некоторую XML-базу данных. (Если вы думаете, что для таких баз данных фаза проектирования не требуется, то глубоко ошибаетесь.) Один из подходов состоит в использовании UML (Unified Modeling Language). Существует де-факто стандарт отображения UML в XML. Имеется соответствующая промышленная поддержка.

Когда мне говорят, что MS Explorer теперь поддерживает XML, я громко смеюсь. Очевидно, что стандартный браузер понимает только подмножество XML, а определенные пользователями теги просто игнорирует. Насколько я понимаю, возможны два решения для обеспечения адекватного восприятия XML-документов на стороне пользователя. Первый (очевидный) подход - создание специализированных браузеров, понимающих смысл DTD заданного набора XML-документов. Второй подход состоит в использовании Java-апплетов. Он универсален и обеспечивает возможность правильной работы с XML-документами с любого стандартного браузера.

Если возникает желание создать на основе XML распределенную информационную систему, то, конечно, потребуется использование дополнительного программного обеспечения промежуточного уровня (middleware). Для меня предпочтительнее была бы CORBA, но возможны решения и на основе COM/DCOM или RMI.

Наконец, я глубоко уверен, что какие бы новые языки запросов не были придуманы для XML-баз данных, будет жить язык SQL.Рано или поздно понадобится реализовать SQL для работы с XML-базами данных, обладающими реляционной структурой. Тогда и пригодится инженерия традиционных SQL-ориентированных СУБД.

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

Модель объектов JavaScript

В модели JavaScript самым старшим объектом является объект window - считается, что все происходящее с документом вложено в окно. У окна имеется несколько объектов-свойств: location, history, document, navigator. Это не полный перечень объектов окна, но для иллюстрации модели данных JavaScript он достаточен.

Объект location ассоциируется с полем location браузера, где отображается URL загруженного в окно документа. У location есть свойства и методы. При изменении значения свойства location или при вызове метода происходит перезагрузка документа. При перезагрузке может пополняться защищенный массив объекта history - множество URL, которые посещал пользователь. Основным способом использование history являются методы window.history.back(), window.history.forward() и window.history.go(-1).

Объект navigator позволяет отображать документ в соответствии с требованиями браузера и его настройками. Подчинение этого объекта window выглядит несколько нелогично: несмотря на множество обслуживаемых окон программа браузера одна. Наиболее полезны свойства объекта navigator, например, фрагмент кода позволяет загрузить страницы по типу навигатора. <html> <head> <script> if(window.navigator.appName== <Microsoft Internet Explorer>) window.location.replace (<explorer.htm>); </script> </head> <body> ... </body> </html>

Если необходимо проверить исполняемость Java-кода на стороне браузера, например, для загрузки страницы с апплетом или без него, то это можно сделать, применив соответствующий метод объекта navigator.

Объект document ассоциирован с телом документа и включает в себя другие объекты, которые могут быть поименованы, как, например, объекты IMG или FORM, а также могут входить во встроенный массив, как, например, гипертекстовые ссылки (links[] ).

Первоначально в JavaScript особое внимание уделялось формам. По этой причине к формам относится наибольшее число классов объектов документа. Это и сама форма объект FORM, и элементы формы: поля ввода (input) различных типов, меню (select) и его составляющие (options), поля ввода больших блоков текста (textarea).

У каждого из этих объектов достаточно большое количество свойств и методов.

Наибольших визуальных эффектов достигают за счет изменения свойства src объекта IMG, который может быть поименованным объектом документа. Он также входит во встроенный массив document.images[].

В JavaScript можно изменять значения гипертекстовых ссылок, а также указывать JavaScript-код вместо гипертекстовой ссылки, используя схему URL javascript. Это позволяет, в частности, отказаться от кнопок в формах и отправлять данные формы, нажимая на гипертекстовую ссылку.

Таким образом, видно, что модель данных JavaScript - это дерево. К его объектам принято обращаться по составным именам, например: window.document.cookie - строка ассоциативный массив "волшебных ключиков", window.document.forms.length - число форм в документе, window.document.images[0].src - URL первой картинки документа, window.location.href - URL загруженного в данный момент документа, window.frames.length - число фреймов в документе.

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

Особенность модели событий в JavaScript заключается в том, что события жестко привязаны к объекту. Например, у гипертекстовой ссылки у элемента ... может быть событие onMouseover, а у элемента IMG такого события, а, следовательно, и обработчика этого события, быть не может. Логика в этом есть: IMG - это пассивный объект. В него никто не будет тыкать курсором мыши и по умолчанию при проходе курсора над IMG информация на экране не меняется. У пассивного объекта нет функций обработчиков событий, которые можно было бы заменить JavaScript-кодом.

Другое дело гипертекстовая ссылка. При проходе курсора мыши над ней в строке статуса отображается URL, при выборе мышью ссылки происходит переход на другую страницу - по крайней мере, три стандартных обработчика событий у гипертекстовой ссылки имеется.

Кстати сказать, для свойств объектов в модели JavaScript определены свои правила инициализации. Например, размер картинки, если он только не указан явно в элементе разметки IMG, будет определяться первой картинкой. Все остальные картинки будут масштабироваться в этот размер независимо от их реальных линейных размеров. Аналогичное "поведение" характерно и для кнопок. Их размер определяется первой надписью, значение атрибута value элемента разметки INPUT. Это сделано для того, чтобы не переформатировать загруженный документ.

С точки зрения традиционного программирования наличие стандартных обработчиков событий и возможность изменения свойств - это вопрос инициализации данных и резервирования места под код и значения переменных. В JavaScript он решается в момент загрузки документа, когда создаются все встроенные объекты документа. После того, как произошло событие Load (обработчик onLoad элемента разметки BODY), встроенные объекты больше не создаются. По этой же причине при использовании метода

Моделирование Элементов данных для Бизнес объектов.

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

На рис 3. изображена трехступенчатая схема реализации модели сообщения.

Рис 3.

Шаг 1 - ручное преобразование в Бизнес модель (БМ) на основе использования Руководства по разработки сообщений EDIFACT. При этом преобразовании имеется в виду перенос синтаксиса элементов EDIFACT всех спецификаций и выделение функциональной спецификации на содержание информации и ее структуры.

Шаг 2 - преобразование БМ в UML Модель сообщений. Преобразование поддерживается программным комплексом моделирования UML, используются такой аппарат как класс диаграмм, класс списка атрибутов и т.д.

Шаг 3 - создание соответствия Бизнес модели XML/DTD и XML-схемы. Данное преобразование осуществляется специально разработанным программным обеспечением.

Шаг 4 - (необязательный) Возможность запомнить образ UML Модели сообщения и создание домена транспортной модели для использования накопленного опыта при разработке других типов сообщения.

Точное отражение EDIFACT структуры включает имена сегментов, составных и отдельных элементов данных.

Сообщение UN/EDIFACT можно разобрать на следующие самостоятельные единицы, вложенные друг в друга:

Сообщение Сегмент Элемент данных Клалификатор

Осуществление ручного переноса (шаг 1) структуры сегмента сообщения в термины описания XML/DTD требует хорошего понимания структуры сообщения и знания стандарта UN/EDIFACT. Ниже приведен пример преобразования в DTD начального сегмента сообщения - BGM.

Структура сегмента BGM в соответствии со спецификацией :

#гр.эл. #спр описание элемента данных обяз/необ формат даннных M/C данных ____________________________________________________________________________ 010 C002 DOCUMENT/MESSAGE NAME C 1001 Document/message name, coded C an..3 1131 Code list qualifier C an..3 3055 Code list responsible agency, coded C an..3 1000 Document/message name C an..35 020 C106 DOCUMENT/MESSAGE IDENTIFICATION C 1004 Document/message number C an..35 1056 Version C an..9 1060 Revision number C an..6 030 1225 MESSAGE FUNCTION, CODED C an..3 040 4343 RESPONSE TYPE, CODED C an..3 ____________________________________________________________________________

Таблица 1

Преобразовывая сегмент сообщения BGM, опуская неиспользуемые клалификаторы, мы получим следующий вид DTD:

____________________________________________________________________________ <?xml version="1.0"> <!-BGM : Beginning of Message --> <!ELEMENT MessageId (#PCDATA) > <!ATTLIST MessageId UN-EDIFACT:Segment CDATA #FIXED "BGM" UN-EDIFACT:Attributes CDATA #FIXED "1001 MessageTypeCode 1060 RevisionNo 1225 MessageFunction 4343 ResponseType" MessageTypeCode CDATA #FIXED "CustomsDeclaration" RevisionNo CDATA #IMPLIED MessageFunction (%Confirmation; "Original" ResponseType (%Response;) "Accepted" Constraints CDATA #FIXED "an..35" > ____________________________________________________________________________

Подходя комплексно к моделированию всего сообщения, используются как информация из базовых сегментов, таких как NAD, RFF, DOC и пр., так и учитывается их семантика и месторасположение.

При создании Бизнес модели используются следующие принципы:

Бизнес модель разделена на следующие секции: реквизиты сообщения, стороны, таможенные отметки, упаковка, товары, документы, коды; основные сегментные группы или сегменты корневого уровня должны соответствовать секции БМ. термины данных БМ могут порождаться из других элементов данных EDIFACT или из значения кодов для определенных элементов данных; подсекции бизнес модели должны быть основаны в соответствии с надобностями, понимания бизнес операций. Это не обязательные предлагаемые структуры составных элементов данных или группы сегментов; Использование термина данных в БМ на уровне кодов данных сслылается на свю "концепцию кода" имена БМ должны быть специфицированы достаточным для понимания; в БМ использовать смысловую семантику, так например таг, описывающий перевозимые товары может именоваться GoodItems дублирование имен недопустимо.

Моделирование Web и запросы

Если Web рассматривается как большая, графового типа база данных, естественно формулировать запросы, которые выходят за рамки основной парадигмы информационного поиска, поддерживаемой современными механизмами поиска, и принимают во внимание структуру. Имеется в виду не только внутренняя структура страниц Web, но и внешняя структура связей, которые их соединяют. В часто цитируемой статье об ограничениях гипертекстовых систем [Hal88] Халаш говорит:

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

3.1. Структурный информационный поиск

Первыми инструментальными средствами для обработки запросов в Web, были известные поисковые машины, которые теперь широко развернуты и активно используются. Они основаны на поисковых индексах слов и фраз, встречающихся в документах, обнаруженных "роботами" (crawler) Web. Совсем недавно были предприняты усилия, направленные на преодоление ограничений этой парадигмы за счет использования в запросах структуры связей. Например, в [Kle98], [BH98] и [CDRR98] предлагается использовать структуру Web для анализа многочисленных сайтов, выдаваемых поисковой машиной в качестве релевантных запросу, с тем, чтобы выделить из них те, которые, вероятно, являются авторитетными источниками по интересующему вопросу. Для того, чтобы поддержать анализ связности (connectivity) для этого и других приложений (например, для эффективных реализаций языков запросов, описанных ниже), быстрый доступ к структурной информации обеспечивается сервером связности [BBH+98]. Прототип поисковой машины Web следующего поколения Google [BP98] интенсивно использует структуру Web для повышения производительности функционирования "робота" и индексирования. Другие методы, опирающиеся на использование структуры связей, предлагаются в [PPR96, CK98].

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

3.2. Родственные парадигмы запросов

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

Гипертекстовые/документальные языки запросов: Ряд моделей и языков запросов для структурированных документов и гипертекстов был предложен еще в период, предшествующий появлению Web. Так, Абитебул и др. [ACM93] и Кристофидес и др. [CACS94] отображают документы в объекты объектно-ориентированной базы данных посредством семантических действий, присоединенных к грамматике. Далее можно делать запросы относительно такого представления базы данных с использованием языка запросов базы данных. Новый аспект этого подхода заключается в возможности производить запросы относительно структуры с помощью переменных-путей. Гутинг и др. [GZC89] моделируют документы, использующие вложенные упорядоченные отношения и используют некоторое обобщение алгебры вложенных отношений как язык запросов. Бири и Корнацкий [BK90] предлагают логику, формулы которой специфицируют шаблоны на графе гипертекста.

Графовые языки запросов: Исследования, связанные с использованием графов для моделирования баз данных, которые были стимулированы такими приложениями, как разработка программного обеспечения и управление компьютерными сетями, привели к созданию языков целого ряда языков, например, G, G+ и GraphLog [CMW87, CMW88, CM90], основанных на графах. В частности, G и G+ основаны на помеченных графах. Они поддерживают использование в запросах правильных выражений путей и графовых конструкций.

Язык GraphLog, семантика которого основана на Datalog, был применен в [CM89] для гипертекстовых запросов. Переденс и др. [PdBA+92] разработали графовый язык запросов для объектно-ориентированных баз данных.

Языки запросов для слабоструктурированных данных: Такие языки запросов для слабоструктурированных данных, как Lorel [AQM+97], UnQL [BDHS96] и STRUDQL [FFLS97], также используют помеченные графы как гибкую модель данных. В отличие от графовых языков запросов, они делают акцент на возможности запрашивать схему и приспосабливаться к нерегулярностям в данных, таких, например, как опущенные или повторяющиеся поля, неоднородные записи. В аналогичной работе из области объектно-ориентированных систем [Har94] предложены модели и запросы с "недостаточной схемой" (schema-shy) для управления информацией относительно артефактов разработки программного обеспечения.

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

3.3. Языки запросов первого поколения для Web

Авторы языков запросов первого поколения для Web стремились сочетать в них возможности запросов, основанных на содержании, присущие поисковым машинам Web, с возможностями запросов, основанных на структуре, подобными тем, которые характерны для систем баз данных. Такие языки, к числу которых относятся W3QL [KS95], WebSQL [MMM97, AMM97a] и WebLog [LSS96], сочетают в себе условия, налагаемые на образцы текста, появляющиеся в документах, с графовыми шаблонами, описывающими структуру связей. Далее мы будем использовать WebSQL для демонстрации примеров запросов, возможных в языках такого рода.

Язык WebSQL: В языке WebSQL предлагается моделировать Web как реляционную базу данных, состоящую из двух (виртуальных) отношений: Документ и Якорь.

Отношение Документ содержит по одному кортежу для каждого документа из Web, а отношение Якорь - по одному кортежу для каждого якоря в каждом документе из Web. Такая реляционная абстракция Web позволяет нам использовать для формулировки запросов язык, подобный SQL.

Если бы Документ и Якорь были фактическими отношениями, мы могли бы просто использовать SQL, чтобы записывать на нем запросы. Но поскольку эти отношения являются полностью виртуальными и не имеется какого-либо способа производить над ними вычисления, мы не можем оперировать ими непосредственно. Семантика WebSQL зависит от материализации частей этих отношений путем спецификации представляющих интерес документов во фразе FROM запроса. Основным способом материализации части Web является навигация из известных URL. Для описания такой навигации используются правильные выражения путей. Атом такого правильного выражения может иметь форму d1 = > d2, означающую, что документ d1 указывает на d2, и d2 хранится на ином сервере, чем d1. Он может иметь также форму d1 - > d2, которая, в свою очередь, означает, что d1 указывает на d2, и d2 хранится на том же самом сервере, что и d1.

Предположим, например, что мы хотим найти список триплетов вида (d1, d2, метка), где d1 - документ, хранимый на нашем локальном сайте, d2 - документ, хранимый где-либо еще, и d1 указывает на d2 с помощью связи, помеченной меткой. Допустим также, что все наши локальные документы достижимы из www.mysite.start. Тогда указанную задачу можно решить с помощью запроса:

SELECT d.url, e.url, a.label FROM Document d SUCH THAT <www.mysite.start> -> d, Document e SUCH THAT d => e, Anchor a SUCH THAT a.base = d.url WHERE a.href = e.url

Предложение FROM порождает экземпляры двух переменных, определенных на отношении Документ, - d и e, и одной переменной a - на отношении Якорь. Области определения переменной d принадлежит каждый локальный документ, достижимый из начального документа, а e принимает значения на множестве всех не локальных документов, достижимых непосредственно из d.

В свою очередь, значением переменной a может являться каждая связь, которая исходит из документа d. Дополнительное условие, предписывающее, чтобы целевым документом связи a был документ e, задается предложением WHERE. Другим способом материализации части отношений Документ и Якорь является использование условий, налагаемых на содержание (content condition). Например, если для нас представляли интерес только документы, которые содержат строку "база данных", мы могли бы добавить в предложение FROM условие: d MENTIONS "база данных". В этом случае в реализации использовались бы поисковые машины для генерации возможных документов, удовлетворяющих условию NENTION.

Другие языки: Язык W3QL [KS95] подобен, по существу, WebSQL, с некоторыми значительными различиями: он использует внешние программы (аналогично определяемым пользователем функциям в объектно-реляционных языках) для спецификации условий, налагаемых на содержание файлов, а не формирование условий в синтаксисе языка, и это обеспечивает механизмы для обработки форм, встречающихся в процессе навигации. В работе [KS98] Конопницкий и Шмуэли описывают планируемые расширения, позволяющие превратить W3QL в то, что мы называем теперь языками второго поколения. Эти расширения предусматривают моделирование внутренней структуры документов, иерархическое моделирование Web, в котором явно фигурирует понятие Web-сайта, а также отказ от использования метода внешних программ для спецификации в пользу обобщенного расширяемого метода, основанного на стандарте MIME.

WebLog [LSS96] отличается от рассмотренных выше языков использованием дедуктивных правил вместо SQL-подобного синтаксиса (см. описание FLORID ниже).

WQL, язык запросов проекта WebDB [LSCH98], подобен WebSQL, но он в большей мере поддерживает функциональные возможности SQL, допуская, например, агрегацию и группирование, и, кроме того, обеспечивает ограниченную поддержку запросов внутридокументной структуры. Это обстоятельство позволяет отнести его к классу языков, обсуждаемых в следующем подразделе.

3.4. Второе поколение: Языки манипулирования данными Web

Рассмотренные выше языки интерпретируют страницы Web как атомарные объекты с двумя свойствами: они могут содержать или не содержать некоторые текстовые образцы и они могут указывать на другие объекты. Опыт использования таких языков показывает, что имеется две основные области приложений, для которых они могут быть полезны. Одна из них, рассматриваемая в разделе 4, - создание оболочек (wrapping) для данных, трансформация и реструктуризация данных. Вторая из этих областей - создание и реструктуризация Web-сайтов - обсуждается в разделе 5. В обеих этих областях приложений часто оказывается существенной возможность иметь доступ к внутренней структуре страниц Web из языка запросов, если мы хотим, чтобы декларативные запросы могли оперировать большой частью задачи. Например, задача извлечения множества кортежей из HTML-страниц сайта Internet Movie Database требует синтаксического анализа HTML-страниц и избирательного доступа к некоторым поддеревьям в дереве синтаксического анализа.

В этом подразделе мы опишем языки запросов второго поколения для Web, которые мы называем "языками манипулирования данными Web". Эти языки превосходят языки первого поколения в двух важных аспектах. Прежде всего, они обеспечивают доступ к структуре объектов Web, которыми они манипулируют. В отличие от языков первого поколения, они моделируют внутреннюю структуру документов Web, а также внешние связи, которые их соединяют. Они поддерживают связи для моделирования гиперссылок, а некоторые из них поддерживают также упорядоченные совокупности записей для более естественного представления данных. Во-вторых, эти языки обеспечивают возможности создания новых сложных структур в результате запроса. Поскольку данные в Web обычно являются слабоструктурированными, в этих языках придается особое значение поддержке возможностей для работы со слабоструктурированными данными. Далее кратко описываются три языка этого класса: WebOQL [AM98], STRUQL [FFLS97] и FLORID [HLLS97].

Multipart: общий синтаксис

Поле Content-Type многочастного письма требует одного параметра, "boundary", который определяет границы вложения. Границей является строка, состоящая из двух символов "-" (десятичный код 45) и значения параметра 'boundary' из поля заголовка Content-Type.

ЗАМЕЧАНИЕ: Два символа "-" используются для совместимости с более ранним методом вложения писем, описанным в RFC 934 и для облегчения поиска границ. Однако, многочастные письма MIME не полностью совместимы с RFC 934; в частности, они не подчиняются соглашению RFC 934 по экранированию строк символом "-", так как с каждым новым уровнем экранирования длина строк увеличивается. А поскольку SMTP-транспорты часто обрезают длинные строки, этот механизм становится неприменимым в случае многоуровневой структуры письма типа 'multipart'.

ВНИМАНИЮ ПРОИЗВОДИТЕЛЕЙ ПО: синтаксис параметров поля Content-Type таков, что зачастую необходимо значения границ в параметре 'boundary' заключать в кавычки. Это не всегда требуется, но никогда не повредит. Программистам следует изучить синтаксис внимательно, чтобы не допустить ошибок в поле Content-Type. Типичное поле Content-Type для типа 'multipart' может выглядеть следующим образом: Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08jU534c0p

Но в следующем примере содержится ошибка: Content-Type: multipart/mixed; boundary=gc0p4Jq0M:2Yt08jU534c0p

(из-за двоеточия), которая может быть исправлена следующим образом: Content-Type: multipart/mixed; boundary="gc0p4Jq0M:2Yt08jU534c0p"

Это означает, что тело письма состоит из нескольких частей, каждая из которых соответствует синтаксису письма RFC 822, за исключением того. что область заголовка может быть абсолютно пустой и начальная граница каждой части отмечена последовательностью: --gc0p4Jq0M:2Yt08jU534c0p

Нужно обратить внимание, что метка границы части письма должна располагаться в начале строки, то есть, сразу же после признака конца строки CRLF. Причем, последовательность CRLF полагается элементом метки границы, а не последним элементом тела предыдущей части (так как тело предыдущей части может неоканчиваться концом строки, что принципиально важно в случае бинарных данных.

Если же тело предыдущей части оканчивается концом строки, то метке границы соответственно должны предшествовать два конца строки). Сразу за меткой границы должен следовать конец строки (CRLF), или при отсутствии заголовка следующей части письма, два конца строки.

Метка границы не должна иметь длину более 70 символов, не считая два начальных дефиса.

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

Обычно оставляется пространство для дополнительной информации перед первой меткой границы и после последней. Обычно его следует оставлять пустым, и обработчики почты должны игнорировать все, что в этом пространстве содержится.

ЗАМЕЧАНИЕ: Эти области приамбулы и эпилога обычно не используются из-за отсутствия точной семантики для обработки этих областей почтовыми шлюзами, однако, многие программные MIME-продукты считают удобным помещать туда пояснительную информацию для получателей, которые пользуются до-MIME'овским ПО. По этой причине, MIME-совместимые программы должны игнорировать эти области.

ЗАМЕЧАНИЕ: Поскольку метки границы не должны появляться внутри тел частей письма, почтовая программа, создающая письмо, должна иметь алгоритм, позволяющий автоматически подобрать уникальную последовательность, не встречающуюся в теле ни одной из частей, либо имеющую минимальную вероятность появления, если данные предварительно не сканируются на наличие таковой.

В качестве простого примера предлагается двухчастное письмо, вторая часть которого оканчивается признаком конца строки, а первая нет: From: Nathaniel Borenstein To: Ned Freed Subject: Sample message MIME-Version: 1.0 Content-type: multipart/mixed; boundary="simple boundary" Это приамбула. Должна быть игнорирована --simple boundary Это простой ASCII-текст. Он НЕ оканчивается признаком конца строки. --simple boundary Content-type: text/plain; charset=us-ascii Это простой ASCII-текст.

Он оканчивается признаком конца строки. --simple boundary-- Это эпилог. Тоже должен игнорироваться MIME-программами.

Часть письма, в свою очередь, также может иметь тип 'multipart', то есть. быть многочастным телом, но при этом метки границ, использующиеся во внешнем и во внутреннем multipart-телах, должны отличаться друг от друга.

Использование типа 'multipart' в одночастном письме может быть полезно в некоторых контекстах и не запрещено.

Единственным обязательным параметром для типа 'multipart' является параметр 'boundary', состоящий из 1-70 символов без хвостовых пробелов (которые могут быть удалены в процессе пересылки, и тогда почтовая программа получателя не сможет разделить вложенные части). граница := 0*69<символов границы> символ_границы_кроме_пробела символ границы := символ_границы_кроме_пробела / " " символ_границы_кроме_пробела := ЦИФРА / БУКВА ЛАТИНСКОГО АЛФАВИТА / "'" / "(" / ")" / "+" /"_" / "," / "-" / "." / "/" / ":" / "=" / "?"

Общий вид многочастного тела - следующий: многочастное тело := приамбула вложения признак_конца эпилог вложение := разделитель часть_тела CRLF разделитель := "--" метка_границы CRLF ; метка границы должна браться из поля Content-Type. ; Не должно быть пробелов между "--" и меткой границы. признак конца := "--" метка_границы "--" CRLF ; Опять, без пробела перед "--", приамбула := игнорируемый текст эпилог := игнорируемый текст игнорируемый текст := *(*текст CRLF) часть_тела := <письмо RFC 822, со всеми необязательными полями заголовка>

ЗАМЕЧАННИЕ: В некоторых транспортах такие ограничения RFC 822, как использование тольеко печатных символов в теле, могут не действовать. Ослабления таких ограничений должны быть истолкованы как локальные расширения определения тела письма настолько, насколько они поддерживаются почтовым транспортом и адекватно документированы в поле заголовка Content-Transfer-Encoding.Однако, ни при каких обстоятельствах в заголовках как письма, так и его частей, не должно содержаться каких-либо символов, кроме US-ASCII.

На примере прогнозов погоды с Yahoo.com

Тотоев Александр,

Добре, господа!

Пример предназначен для тех, кто начинает работать с php, и не только для них.

Результатом работы программы(скрипта) является прогноз погоды на 5 дней для любого, интересующего Вас города, выводимый в виде, который нравится именно Вам, а не дизайнерам сайта-донора.

Информация в таких случаях берется с известных серверов прогноза погоды (где не пишут фразу "запрещено использование информации" и т.п.). В данном случае используется сервер http://weather.yahoo.com , на котором есть страницы с погодой для довольно большого количества городов, и практически всегда можно найти если не интересующий Вас город, то ближайший ему и идентичный по погодным условиям.

Это законченный проект, работающий на сайте .

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

Посему, скрипт состоит из 2-х частей:

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

На распутье

Как известно, корпорация Microsoft всерьез заинтересовалась Интернетом с большим опозданием. Тем больше людских, финансовых и рекламных ресурсов этой империи брошено сейчас на завоевание нового континента. Microsoft прекрасно знает, что выигрывает всегда тот, кто диктует правила игры. Поэтому нет ничего удивительного в том, что борьба сейчас идет не за создание особо качественного продукта (да это и невозможно при той скорости, с которой Netscape и Microsoft выбрасывают на рынок все новые и новые версии своих броузеров) и даже не за завоевание симпатий максимального количества пользователей, а в первую очередь за признание и бесповоротное утверждение новых стандартов. Нынешнее отношение Microsoft к Интернету лучше всего передается словосочетанием, встретившимся в одной из официальных публикаций корпорации на эту тему - agressive embrace, "агрессивное объятие"...

Что же делать в этой ситуации нам - простым смертным, развлекающимся время от времени рисованием страничек для World Wide Web? На кого держать равнение? Имеет ли смысл менять свои привычки так же часто, как меняется мода в компьютерном мире? Большинство, вероятно, ответят на этот вопрос пожиманием плечами - и в самом деле, немало страниц в Web вполне прилично выглядят даже в броузере Lynx, так что моральное устарение им совершенно не грозит (как известно, старомодным может выглядеть только то, что когда-то было модным).

Однако всем, кого любопытство или жажда самовыражения выводят за рамки двух десятков базовых тегов HTML, жить теперь станет куда сложнее - хотя, наверно, и интереснее. Даже если вы не собираетесь пользоваться ActiveX, теперь, когда Internet Explorer почти не уступает Netscape Navigator по набору возможностей, особенно остро встает вопрос о совместимости всех нестандартных компонентов с обоими этими броузерами. Я уверен, что уже в самое ближайшее время умение создавать такие страницы, которые выглядят более-менее одинаково в двух главных броузерах Интернета, перейдет в разряд жизненно необходимых.

Впрочем, если вся эта суета вам не по душе, вы можете попробовать переждать период бурь и войн - вероятно, рано или поздно кто-то один выйдет из схватки победителем... или же (что куда менее вероятно) все станут настолько совместимы друг с другом, что проблемы отпадут сами собой. Когда это будет? Если вспомнить, что еще два года назад индустрии броузеров попросту не существовало, - вероятно, ждать осталось не так уж и долго. Вместо этого планы Microsoft дали повод острословам придумать новое словечко - "Winternet", эдакий гибрид "Windows" и "Internet"... или, попросту говоря, такой Интернет, каким Microsoft видит его в своих мечтах.

НАЗЫВАТЬ ВЕЩИ СВОИМИ ИМЕНАМИ

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

Вот фрагмент HTML:

<H1>Еditor Сontacts</H1> <H2>Имя: Джонатан Эйнджел</H2> <P>Должность: старший редактор</P> <P>Издание: Network Magazine</P> <P>Улица и дом: Гариссона, 600 </P> <P>Город: Сан-Франциско</P> <P>Штат: Калифорния</P> <P>Индекс: 94107</P> <P>Электронная почта: jangel@mfi.com</P>

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

В случае XML тот же самый фрагмент будет представлен следующим образом (и сохранен в файле EDITORS.XML).

<?xml version = “1.0” ?> <editor_contacts> <editor> <first_name>Джонатан</first_name> <last_name>Эйнджел</last_name> <title>старший редактор</title> <publication>Network Magazine</publication> <adress> <street>Гариссона, 600 </street> <city>Сан-Франциско</city> <state>Калифорния</state> <zip>94107</zip> </address> <e_mail>jangel@mfi.com</e_mail> </editor> </editor_contacts>

XML, лишь несколько более «многословный», чем HTML, намного упрощает определение того, что собой представляют и где находятся поля данных. В XML теги не могут накладываться, как в HTML (что не поощряется, но допускается большинством программ разбора HTML). Однако они могут быть вложены в друг друга.

На самом деле, вложение даже поощряется как способ создания иерархии данных (подчиненные или равноправные отношения). Как видно из приведенного примера, такие элементы, как <first_name> и <e_mail>, содержат данные, в то время как другие (<address>) присутствуют только в целях структурирования. Теги начала и конца элемента являются основными используемыми в XML разметками, но ими дело не исчерпывается. Например, элементам могут быть присвоены атрибуты. Эта возможность аналогична имеющейся в HTML, где, например, элементу <table> может быть присвоен атрибут align=”center”. В XML элемент может иметь один или более связанных с ним атрибутов, причем при составлении документа вы можете выдумать их столько, сколько пожелаете, например <publication topic=”networking” circulation=”controlled”>. Документы XML могут содержать ссылки на другие объекты. Ссылки представляют собой строку, начинающуюся с амперсанта и заканчивающуюся точкой с запятой. Эти ссылки позволяют, в частности, вставить в документ специальные символы, включение которых самих по себе могло бы сбить с толку программу разбора. Например, чтобы поместить в документ знак «меньше, чем» (<) вы должны вставить ссылку <, а чтобы вставить сам амперсант — ссылку &, и т. д. До сих пор все так же, как и в HTML. Однако ссылки XML на объекты предоставляют гораздо больше возможностей, так как они могут ссылаться на определенные автором разделы текста в том же самом или в другом документе. Например, ссылки на объекты позволяют применить объектно-ориентированный подход при создании журнальной статьи: <article> &introduction; &body; &sidebar; &conclusion; &resources; </article>

Другими видами разметки XML являются комментарии (они выделяются точно так же, как в HTML) и инструкции по обработке. Инструкциям по обработке предшествует знак вопроса. Они описывают, что именно программа разбора должна использовать для интерпретации конкретного документа или его раздела.Например, инструкция <?xml version = 1.0”?> сообщает программе разбора XML, что обрабатываемый документ действительно составлен с помощью XML. С другой стороны, инструкция <?rtf \page?> служит для вызова программы разбора RTF и вставки символа конца страницы. Наконец, разделы символьных данных — это части документа, рассматриваемые исключительно как символьные данные, не подвергающиеся разбору. Они выглядят следующим образом: <![CDATA[

Этот текст, даже если он содержит элементы кода HTML, такие, как <B>жирныйшрифт</B> или <H1>заголовок</H1>, не подвергается грамматическому разбору. Вместо этого он отображается как есть. ]]>

NCSA Telnet

NCSA Telnet версии 2.3 для PC обеспечивает интерактивный доступ с IBM PC к машинам, объединенным TCP/IP сетью. NCSA Telnet представляет собой стандартный Telnet DARPA с добавлением некоторых особенностей, использующих преимущества PC.

NCSA утилиты

Все перечисленные утилиты являются стандартными под UNIX. Их подробное описание имеется в UNIX Manual Pages.

finger - выдает информацию о пользователях;

ftp - представляет собой минимальный стандарт FTP (File Transfer Protocol) сервера, подобного 4.2 BSD UNIX. Поддерживает:

- передачу текстовой (ASCII) и бинарной (IMAGE) информации;

- изменение, создание и удаление директорий;

- печать текущей директории;

- выдачу списка файлов текущей директории согласно спецификациям, установленным по шаблону;

- прием/передачу множества файлов с помощью одной команды и с использованием шаблонов;

- удаление файлов.

Передача текстовой (ASCII) информации между машиной под UNIX и PC под DOS происходит с автоматическим преобразованием формата файлов UNIX-DOS и наоборот.

rcp - Berkeley UNIX утилита в оригинале предназначенная для обмена информацией между машинами: UNIX - UNIX. В случае связи UNIX - DOS используется для передачи бинарных файлов. Для текстовых файлов не поддерживает преобразования форматов. (* отсутствует)

lpq - Выдает информацию о заданиях, находящихся в очереди на печать.

lpr - Посылает задание на печать.

lprm - Посылает множество заданий на печать.

net14 - Утилита, позволяющая программам, использующим 14h прерывание перенаправлять output от MS-Kermit в TCP/IP. (* не опробовано)

rsh - Удаленная оболочка: позволяет выполнять команды shell на удаленной машине. (то же самое что и rexec) (* после использования PC как правило зависает)

setclock - Устанавливает часы PC в соответствии с одним из сетевых серверов.

Некоторые примеры синтаксиса языка Curl.

Язык Curl сочетает в себе возможности форматирования текста, сходные с использованием тагов HTML, и программную функциональность. Правила форматирование текста могут определяться как в самом документе, так и быть загружены или импортированы из внешних файлов.

Команды форматирования текста в языке Curl подразделяются на следующие категории:

форматирования символов и фрагментов текста; форматирование параграфов; включение в текст изображений и объектов и выравнивание текста

Рассмотрим небольшой пример форматирования текста:

{curl 1.6 applet} Заголовок текста {title font-family="Times New Roman", font-size=24pt, color="green", Заглавие текста} Первый параграф {paragraph Первый параграф Первый параграф Первый параграф } Заголовок, с размером по умолчанию. {heading font-size=14pt, color="green", Заголовок 1} {paragraph Второй параграф Второй параграф Второй параграф } Заголовок, с размером 2 {heading level=2, font-size=10pt, color="olive", Заголовок 2} {paragraph Третий параграф Третий параграф Третий параграф }

{curl 1.6 applet} - определитель языка Curl, который указывает на то, что файл содержит апплет, написанный на API 1.6, который может исполняться на Surge plug-in версии 1.1.

- оператор комментария, данный оператор ставится в начале строки; текст который стоит после него, но до конца строки является комментарием.

{title font-family="Font name", font-size=Npt, color="color", text } - оператор описывающий заглавие текста, где font-family - имя шрифта, font-size - размер шрифта, color - цвет текста, text - текст заглавия; определители font-family, font-size и color являются необязательными и если они неописаны, то будут приняты значения текста по умолчанию.

{paragraph font-style="style", text} - оператор описывающий параграф текста, где font-style - стиль шрифта, text - текст заглавия. Может использоваться со следующими операторами text, italic, bold, itemize.

{heading level = N, font-family="Font name", font-size=Npt, color="color", text } - оператор для описания заголовков, где level - предустановленный тип заголовка, font-family - имя шрифта, font-size - размер шрифта, color - цвет текста, text - текст заглавия.

Ниже представлен результат работы вышеприведенного примера:

{italic text} - оператор, устанавливающий на текст атрибут курсива.

{bold text} - оператор, устанавливающий на текст атрибут увеличинной толщины символов.

{text font-style="style" text} - оператор, устанавливающий на текст определенный стиль.

{itemize {item text1} {item text2} {item text3}} - оператор, позволяющий отформатировать текст как список.

{center object} - оператор, выравнивающий объект по центру документа.

{image source={url "image.jpg"}, width=Nin, height=Min} - оператор, включающий в документ файлы с изображениями.

{hrule color="color", height=Npt} - оператор, отображающий в документе горизонтальный разделитель

При форматировании документов можно использовать специальный оператор {set-document-properties margin=Npt, background={url "image.jpg"}, border-width=Mpt, border-color="color"}, где margin - отступ слева, backgroud - фон документа (вместо файла с изображением как параметр может использоваться и цвет фона), border-width - ширина обрамления документа, border-color - цвет обрамления документа.

{curl 1.6 applet} {set-document-properties margin=0.2in, background="beige", border-width=5pt, border-color="olive" } {title font-family="Times New Roman", font-size=24pt, color="green", Документ} {paragraph Определение: от латинского documentum - свидетельство. } {text } {paragraph {text font-size=8pt, {itemize {item Документ - материальный носитель данных с записанной на нем информацией, предназначенной для ее передачи во времени и пространстве.} {item Документы могут содержать тексты, изображения, звуки и т.д. В узком смысле - деловая бумага, юридически подтверждающая какой-либо факт или право на что-то.} } } } {hrule color="olive", height=2pt} {center {italic Статья из \"Советского Энциклопедического Словаря\"}

Результат работы примера:

Для форматирования документа можно также использовать специальные предопределенные стили.

Данная операция производится с помощью оператора {document-style style}. Этот оператор должен предшествовать оператору {set-document-properties ...}. В качестве значений параметра style могут выступать DefaultDocument - содержимое документа отображается на простой странице с белым фоном, этот же стиль применяется по умолчанию, если данный оператор не задан, TocDocument - задает вид страницы с автоматически сгенерированным окном содержания документа, PlainDocument - отображает один объект в отдельную область (Frame) без линеек прокрутки, дополнительные объекты вызывают ошибку, а текст самого вернего уровны игнорируется; данный стиль нужен для отображения графики.

Если вы создаете простой документ, то обычным является перезначение стилей в начале файла, иначе правильным будет создание внешнего файла со стилями и подключения его к документу. Создание стиля осуществляется с помощью оператора {define-text-format ...}.

{define-text-format H1 as heading with level = 1, font-size = 14pt, color = "olive" }

Если нам необходимо подключить внешний файл со стилями, то это можно осуществить с помощью оператора {include ...} до объявления {document-style ...} и {set-document-properties ...}.

Рассмотрим возможности среды Curl по форматированию текста. Эти возможности можно подразделить на следующие категории: работа с символами, работа с параграфами, работа с таблицами и работа с ссылками и изображениями. Основным оператором форматирования для символов является оператор {text ...}, а для параграфов - {paragraph ...}. Приведем небольшой пример использования этих операторов.

{paragraph Я не хочу форматировать весь текст; {text color = "green" только этот текст будет выделен зеленым цветом,} а этот уже не будет. }

Я не хочу форматировать весь текст; только этот текст будет выделен зеленым цветом, а этот уже не будет.

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

Например, оператору {bold ...} соответствует {text font-weight = "bold" ...}.

Форматирование текста	{text ...}	Color	Цвет
		Font-family	Шрифт
		Font-size	Размер шрифта
		Font-style	Стиль шрифта
		Font-weight	Ширина символа
		Text-underline?	Текст подчеркнут
		Text-line-through?	Текст зачеркнут
		Text-vertical-align	Расположение текста
		Text-breakable?	Одной строкой?
		Text-preserve-whitespace?	Работа с пробелами
Форматирование параграфа	{paragraph ...}	Paragraph-first-line-indent	Отступ для 1-й строки
		Paragraph-justify	Выравнивание
		Paragraph-line-spacing	Межстрочное расстояние
		Paragraph-left-indent	Левый отступ
		Paragraph-right-indent	Правый отступ
		Paragraph-after-spacing	Отступ до параграфа
		Paragraph-before-spacing	Отступ после параграфа
Форматирование таблиц	{table ...}	Cell-border-width	Ширина рамки ячейки
		Cell-margin	Отступ до содержимого ячейки
		Cell-border-color	Цвет рамки ячейки
		Cell-border-style	Стиль рамки ячейки
Форматирование изображений		Border-width	Ширина рамки
		Border-style	Стиль рамки
		Border-color	Цвет рамки
		Width	Ширина
		Height	Высота
		Margin	Отступ
		Background	Фон
		Halign	Выравнивание по горизонтали
		Valign	Выравнивание по вертикали

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

{trademark} - символ TM.

{registered-trademark} - символ ®.

{copyright} - символ ©.

{degrees} - символ

.

{em-dash} - символ —.

{en-dash} - символ –.

{bullet} - символ

.

{br} - оператор принудительного переноса текста на следующую строку.

{page-break} - оператор принудительного переноса текста на следующую страницу.

Предопределенные операторы-эквиваленты стандартному оператору {paragraph ...}:

{left-justify ...} - выравнивание по левому краю.

{right-justify ...} - выравнивание по правому краю.

{center ...} - выравнивание по центру.

{blockquote ...} - одинаковые отступы по правому и левому краям.

{pre ...} - вывод блока тескста шрифтом фиксированной ширины.

{heading ...} - заголовок.

{numbered-heading ...} - заголовок с соответствующим номером.

{itemize ...} - ненумерованное перечисление.

{enumerate ...} - нумерованное перечисление.

{item ...} - элемент перечисления.

{definition ...} - элемент описания.

Рассмотрим специальные операторы форматирования:

{title ...} - установка названия документа в окне броузера.

{link [target = browser-string, ] href = {url destination-string}, link-display} - оператор, описывающий ссылку, где browser-string - окно броузера куда будет загружен ресурс загруженный по ссылке, destination-string - адрес ссылки в формате URL, link-display - текст, к которому будет "привязана" ссылка.

{destination name = name-string, [, display]} - оператор, описывающий имя ресурса, на который можно сослаться с помощью оператора {link ...}, где name-string - название ресурса, display - текст.

{link source = {url image-file-string}, [width = width,] [height = height]} - оператор, описывающий изображение, где image-file-string - адрес изображения в формате URL, height и width - высота и ширина изображения.

{hrule [height = distance-value,] [color = color-value]} - оператор, отображающий горизонтальную линию в документе.

Рассмотрим операторы, работающие с таблицами - {table ...}, {row...}, {cell ...}. Структура вложенности этих операторов эквивалента аналогичным тэгам языка HTML.

{table ... {row ... {cell ...} {cell ...} } {row ... {cell ...} {cell ...} } }

{table ...} - оператор, задающий таблицу.

{row ... [colspan = n]} - оператор, задающий столбец таблицы, где colspan - команда слияния n строк.

{cell ... [rowspan = n]} - оператор, задающий строку таблицы, где rowspan - команда слияния n столбцов.

Приведем пример работы данной группы операторов:

{table background="beige", margin=1cm, border-color="red", border-width=2pt, cell-margin=0.5cm, cell-border-width=4pt, cell-border-color="brown", {row cell-margin=0.5cm, {cell color="magenta", I don't really garden} {cell color="purple", I putt around} } {row color="green", cell-margin=0.5cm, {cell I don't use a table saw} {cell I use my teeth} } }

Необязательное поле Content-Description

Возможность ассоциировать некоторую описательную информацию с данными часто очень желательна. например, может быть полезным описать тело, содержащее графическое изображение, как "a picture of the Space Shuttle Endeavor." Этот текст и может быть помещен в поле заголовка Content-Description. описание := "Content-Description" ":" *текст

Описание должно иметь языковую кодировку US-ASCII, хотя механизм, определенный в RFC-1522 может быть использован для не-US-ASCII значений.

Необязательное поле Content-ID

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

Как и значения поля Message-ID, значения поля Content-ID должны быть абсолютно уникальными (для всего мира).

Такой идентификатор может быть использован для идентификации тела письма (части письма) в нескольких контекстах, в часности, для кэширования данных, указываемых с помощью механизма message/external-body. Хотя поле Content-ID является необязательным в общем случае, его использование необходимо в реализациях, генерирующих данные, имеющие дополнительный тип "message/external-body" (поле Content-type). Каждое тело такого типа должно обязательно иметь в своем заголовке поле Content-ID для обеспечения ссылки на такие данные.

Значение поля Content-ID имеет специальную семантику в случае типа multipart/alternative. (См. соотв. пункт).

Новая схема

Хотя практически в любом обзоре XML (не исключая и статью «XML: время пришло») говорится, что грамматика и синтаксис правильно составленного документа XML определяются DTD, скорее всего, дни DTD уже сочтены. На смену DTD должен прийти новый стандарт — XML Schema.

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

Во-вторых, элементы DTD внутри документа XML требуют полного определения всего, что находится внутри этих элементов. Другими словами, никакие подэлементы «на перспективу» не допускаются — если таковые будут присутствовать в документе, то, по определению, документ не будет являться правильно составленным. Между тем определения XML Schema используют модель открытого информационного наполнения, в которой неопределенные элементы вполне допустимы.

В-третьих, DTD ограничиваются только грамматикой и синтаксисом (т. е. отношением одного элемента к другому), тогда как XML Schema может также задавать непосредственные ограничения на тип данных, которые элемент может содержать. Это значительно упрощает реализацию передачи данных приложения по сравнению с более традиционным текстовым документом. Например, точно так же, как это делают разработчики в языках программирования, вы можете явным образом указать, что данная область хранения может содержать только целочисленные данные. Наконец, разработчикам, работающим в средах Wintel, будет весьма удобно то обстоятельство, что XML Schema легко отображается на Microsoft Document Object Model. Таким образом, работающая с документами XML программа может запросить у соответствующей схемы имеющееся определение для элемента документа по своему выбору. Код выглядит следующим образом:

var bookNode = doc.documentElement

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

<Schema name=”schema_sample_1”> ... содержание схемы </Schema>

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

определяет элемент <Inventor> как могущий содержать только текстовые данные.

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

Отмечу также, что в случае правил на базе XML для форматов коммерческих данных вы можете использовать для отображения одной схемы на другую встроенные функциональные возможности преобразования XML — расширяемый язык таблиц стилей (Extensible Stylesheet Language, XSL).

Новые Технологии распространения информации

В последние годы основным средством распространения информации становится Web, поскольку при его использовании:

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

предоставляется удобный интерфейс для поиска и навигации;

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

за счет технологии «тонкого клиента» снижаются требования к аппаратному и программному обеспечению и сокращаются расходы на поддержку клиентского места;

обеспечивается возможность использования независимого от платформы программного обеспечения(Java) и системы представления данных (XML);

информация для сотрудников, партнеров и заказчиков может распространяться через Intranet/Extranet и Internet. За счет этого расширяется пространство доступа к информации и открываются новые пути ведения бизнеса.

В результате информация, необходимая для принятия решений, может передаваться пользователям и приложениям с использованием двух основных технологий:

Web-ориентированных средств Business Intelligence (инструментов для создания отчетов, выполнения OLAP-анализа и data mining), а также пакетов аналитических приложений для Web;

корпоративных Информационных порталов и серверов рассылки.

Важно отметить, что эти технологии не взаимозаменяемы: для максимального эффекта их надо использовать совместно.

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

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

в тех случаях, когда организации

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

Чтобы помочь пользователям применить этот широкий спектр бизнес данных (как для нерегламентируемого доступа, так и для автономной доставки), используется вторая технология — корпоративные информационные порталы.

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

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

Общая информация о работе с NCSA Telnet

Если запуск Telnet осуществляется так:

telnet host1 host2 ..

то пользователю будет предложен login последовательно на каждую из перечисленных машин. Переход к каждой следующей сессии происходит по Alt+N. Открыть новую сессию, с новой машиной можно по Alt+A. После чего появится login на новую сессию. Время соединения с новой машиной может варьироваться от мгновения до нескольких минут, в зависимости от удаленной машины.

Обзор стандарта UN/EDIFACT

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

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

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

Часть справочников (такие как трехзначные коды стран мира, коды валют) использовались до появления стандартов UN/EDIFACT. Эти справочники были пересмотрены и скорректированы с точки зрения использования их в новых стандартах.

В основу стандарта UN/EDIFACT положены следующие принципиальные идеи:

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

Группа сегментов кроме типовых сегментов данных может содержать другие группы сегментов.

Сегменты в группе сообщений могут повторяться некоторое количество раз. Также незаполненные (пустые) сегменты могут опускаться.

Стандартом предусмотрено около 200 различных типов сегментов, из которых составляется сообщение.

На рис. 1 Представлен фрагмент структуры сообщения, на котором видно, как объеденены в группу SG. 8 сегменты TDT-LOC и MEA-EQN которые в свою очередь объединены в группу SG.9 В группе, порядок следования сегментов строго упорядочен, но они могут повторяться, например:

TDT- LOC MEA-EQN MEA-EQN TDT- LOC MEA-EQN

Первый раз, в группе SG.9 сегменты MEA- EQN повторяются два раза, второй раз - один. В группе SG.8 - сегменты TDT- LOC повторяются - два раза.

Сегменты данных состоят из элементов данных, которые могут быть простыми (аналогом является поле данных) и составными (обычно 2-3 поля данных).

На конец 1999 года разработано более 170 стандартных сообщений. Стандартом предусмотрено, что каждое сообщение имеет уникальный 6-значный код из заглавных букв, а каждый сегмент данных имеет 3-значныный код из заглавных букв.

По правилам UN/EDIFACT не предусмотрено использование символов перевода строки и возврата каретки, но для наглядности на каждой строчке расположен отдельный сегмент. Ниже, для примера, показано разобранное на сегменты сообщение ORDERS в стандарте UN/EDIFACT.

UNH+000002+ORDERS:D:96A:UN:EAN008'	Заголовок Сообщения
BGM+220+B00002+9'	Номер заказа
DTM+137:19940202:102'	дата отправки сообщения
NAD+BY+++Stadt- und Universitaetsbibliothek	Имя и адрес покупателя
:Frankfurt+Bockenheimer Landstr. 134-13 8+Frankfurt++60325' RFF+API:DE1141110388'	Идентификатор покупателя
NAD+SU+++DREIER'	Наименование поставщика
CUX+2:DEM:9'	Валюта оплаты
LIN+1'	Позиция заказа 1
PIA+5+3772815359:IB'	Идентификатор ISBN заказа
IMD+F+050+:::Die "Jahrbuecher fuer wissensc haftl:iche Kritik"' IMD+F+060+:::Hegels Berliner Gegenakademie' IMD+F+065+:::Hrsg. von Christoph Jamme' IMD+F+110+:::Stuttgart-Bad Cannstadt' IMD+F+120+:::Frommann-Holzboog' IMD+F+170+:::1994' IMD+F+190+:::Spekulation und Erfahrung' IMD+F+191+:::Abt. 2' IMD+F+192+:::Untersuchungen' IMD+F+194+:::Bd. 27' IMD+F+220+:::Gewebe'	Подробности описания товара
QTY+21:1'	кол-во копий заказа
PRI+AAE:295:CA'	Цена заказа в Нем. марках
UNS+S'	Разделительный сегмент
CNT+2:1'	Общее кол-во позиций - 1
UNT+25+000002'	Общее кол-во сегментов = 25

Сегменты, составляющие сообщение, начинаются с трехбуквенного имени, например UNA, UNH, BGM, DTM и т.д. Оканчивается сегмент символом окончания сегмента - в данном примере апострофом.

Ниже приведены названия некоторых сегментов:

BGM	BEGINNING OF MESSAGE	НАЧАЛО СООБЩЕНИЯ
CUX	CURRENCIES	ВАЛЮТА
DTM	DATE/TIME/PERIOD	ДАТА/ВРЕМЯ/ПЕРИОД
IDM	ITEM DESCRIPTION	ОПИСАНИЕ ПУНКТА

Каждый сегмент состоит из элементов данных. В отличие от имени сегмента, имя элементов данных не указывается в сообщении. Элементы данных разделены разделителями которым является символ "плюс". Так, например сегмент NAD+BY+++Stadtund Universitaets bibliothek:Frankfurt+Bockenheimer.Landstr.134 -138+Frankfurt++ 60325'

Состоит из следующих элементов данных:

Первый элемент	BY
Четвертый элемент	Stadt-und Universitaetsbibliothek:Frankfurt
Пятый элемент	Bockenheimer.Landstr.134-138
Шестой элемент	Frankfurt
Восьмой элемент	60325

Каждый из элементов данных занимает свое определенное место в сегменте. Если какой-либо из элементов данных не требуется, то для его пропуска повторяют разделитель элементов данных (см. в примере - между первым и четвертым элементом расположено три разделителя). Назначение того или иного элемента данных определяется справочником сегментов EDSD, который входит в набор стандартов UN/EDIFACT.

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

Обзор технологий безопасности.

В сравнении с технологиями безопасности, применяемых в Java и HTML, язык Curl является более гибким, простым и защищенным:

простота в использовании - конечному пользователю не надо настраивать политики безопасности; большая гибкость - непривилегированные апплеты, написанные на Curl, являются более функциональными и безопасными, чем апплеты, написанные на Java; более защищенный, чем Java - привилегированные апплеты должны использоваться как можно реже; более защищенный, чем HTML - Curl предлагает безопасность для решения проблем идентификации пользователя.

Одноступенчатое формирование XML-документа

Развитие новых тенденций объединения технологий XML и EDI обеспечивает динамичный процесс формирования электронных документов и взаимодействия между информационными системами. Тенденция объединения XML и EDI является наиболее перспективным направлениям в использование электронных документов.

Рис. 1

На рис.1 представлена схема вариантов обмена Электронными документами для разных (мелких и крупных) компаний. Крупные компании продолжают использовать уже имеющие EDI-системы через VAN сеть (сеть с добавленной стоимостью, т.е. предоставление за плату добавочных услуг). Провайдеры предоставляют такую услугу, как подготовка и обмен EDI-сообщениями по средствам корпоративных сетей. Более мелкие компании, используя технологию XML/EDI осуществляют обмен через Internet.

Один из самых простых вариантов обмена используя XML/EDI технологию - это подготовка XML-докуамента на стороне клиента и отправка на XML-сервер компании, где документ проверяется и преобразуется в стандартное EDI - сообщение и будет передан по Intranet на EDI-сервер компании.

Рис. 2

На рис.2 представлена схема формирования XML документа на клиентской стороне. В ходе начала обмена, клиент принимает от XML сервера шаблон (формально назовем XML шаблон). Текст простого шаблона на примере XML документа "инвойс" может иметь следующий вид:

<?xml version="1.0"> <!DOCTYPE InvoiceForm > <?xml-stylesheet type="text/xsl" server-config="Config.xml" href=" InvoiceForm.xsl" ?>

Элемент <Transaction> включает атрибут id, указывающий номер транзакции имеющий значение "768765324". Элемент <ItemQuantity> описывает количество "пунктов" инвойса, т.е. количество наименований перевозимого товара. Далее, используя язык описания стилей XSL, генерируется HTML форма, которая заполняется данными об отправителе и получателе груза, а также о самом грузе.

Внешнее представление сгенерированной формы принципиального значения не имеет и может быть разработано получателем документа самостоятельно. Также, возможно использование заранее подготовленной HTML формы с параметром id тага Transaction.

Рис. 3

Упрощенный вид генерируемой HTML формы представлен на рис. 3. После инициации события OnClick кнопки "Передача" (SUBMIT) происходит генерация следующего XML документа:

<?xml version="1.0"> <!DOCTYPE Invoice> <Transaction id="768765324"> <InvoiceNum>12345<InvoiceNum>  <DataSend>20000105</DataSend> 

<Consignor> <ConsignorName>OY Valio</ConsignorName>  <Address>  <City>Helsinki</City> <Street/> <Zip>Box 789</Zip> <Country>FI</Country> </Address> </Consignor> <Consignee>  <ConsigneeName>АО Северная столица</ConsigneeName> <Address> <City>Санкт-Петербург</City> <Street>Невский 176</Street> <Zip>194376</Zip> <Country>RU</Country> </Address> </Consignor>

<Goods>  <Item id=1>  <Name>Сыр</Name>  <Qulity>200</Qulity>  <TypeEQU>AAI</TypeEQU>  <Price>300</ Price>  <Currently>FIM</Currently>  </Item> <Item id=2>  <Name>Масло</Name> <Qulity>150</Qulity> <TypeEQU>AAU</TypeEQU>  <Price>500</ Price> <Currently>FIM</Currently> </Item> <Item id=2>  <Name>Варенье</Name> <Qulity>100</Qulity> <TypeEQU>AAU</TypeEQU> <Price>180</ Price> <Currently>FIM</Currently> </Item>

</Goods> </Transaction>

Данный документ принимается XML сервером, который генерирует следующее EDI - сообщение:

UNH+768765324+INVOIC:D:96A:UN:EAN002' BGM+380+12345+9+NA' DTM+3:20000105:102' NAD+SE+++OY Valio++Helsinki++Box 789+Fi' NAD+By+++АО Северная столица ++Saint-Peterburg+Невский 176 + +RU'	Заголовок Сообщения Номер транзакции 768765324 Номер инвойса 12345 Дата выдачи 5.01.2000 Поставщик Valio Адр: Helsinki Box 789 FI Получатель "АО Северная столица" Адр: С-Петербург Пр. Невский 176 Россия
LIN+1' IMD+F+011+:::Сыр' MEA+AAI' QTY+92:200' PRI+INV:300' CUX+2:USD'	Первая позиция Наим. Сыр Ед.изм- кг Кол-во 200 кг Цена 300 за кг Валюта - USD
LIN+2' IMD+F+011+:::Масло' MEA+AAU' QTY+92:150' PRI+INV:500' CUX+2:USD'	Вторая позиция Наим. Масло Ед.изм- упак Кол-во 150 упак Цена за упак - 500 Валюта - USD
LIN+3' IMD+F+011+:::Варенье' MEA+AAU' QTY+92:100' PRI+INV:180' CUX+2:USD'	Третья позиция Наим. Варенье Ед.изм- упак Кол-во 100 упак Цена 180 за упак Валюта - USD
UNS+S' CNT+4:3' UNT+26+12345'	Контрольная секция Общее кол-во позиций- 3 Кол-во сегментов - 26 и Номер сообщения - 12345

Особой задачей для семантической проверки и разбора XML документа и формирования EDIFACT сообщения является разработка Таблицы определения данных - DTD. При разработке DTD, учитывая иерархическую структуру EDIFACT сообщения, разрабатывается объектная модель документа - DOM. На рис 3 представлена иерархическая схема сообщения INVOICE.

В рассматриваемом EDIFACT сообщении INVOICE можно выделить сегменты и сопоставить их с объектами ELEMENT объектной модели. В левой части таблицы представлены DOM элементы, а в правой соответствующие им сегменты или части сегментов. Значок # указывает, что в данном месте должно находится значение из соответствующего элемента DOM.

Корневой элемент Name= "Transaction" Attr "id = #"	Сегмент UNH UNH +#+INVOIC:D:96A:UN:EAN002'
Элементы: Name ="InvoiceNum" Value = #	Сегмент BGM BGM+380+#+9+NA'
Name ="Consignor "	Сегмент NAD NAD+SE+++#01++#02'
Дочерние элементы "Consignor " Name = "ConsignorName" Value = #01 Name ="Addsress" Value = #02
Name ="Consignee " Дочерние элементы "Consignee " Name ="ConsigneeName " Value = #01 Name ="Addsress" Value = #02	NAD+BY+++#01++#02'
Name ="Addsress" Дочерние элементы "Addsress" Name ="City " Value = #01 Name ="Street" Value = #02 Name ="Zip" Value= #03 Name ="Country" Value= #04	Часть Сегмента NAD #01+#02+#03+#04
Name ="Goods" Дочерние элементы "Goods" Name ="Item "	Идентификатор группы сегментов: LIN-IMD-QTY-MEA-PTI-CUX
Name ="Item" Attr "id = #" Дочерние элементы "Item" Name ="Name" Name ="Qulity" Name ="TypeEQU" Name ="Price " Name ="TypeCur"	Сегмент LIN LIN+#'
Name ="Name" Value = #	Сегмент IMD IMD+F+011+:::#'
Name ="Qulity" Value = #	Сегмент QTY QTY+92:#'
Name ="TypeEQU " Value= #	Сегмент MEA MEA+#'
Name ="Price" Value= #	Сегмент PRI PRI+INV:#'
Name ="TypeCur" Value= #	Сегмент CUX CUX+2:#'

<

Интерпретация содержания сегмента осуществляется следующим образом: значение тага <InvoiceNum> из текста нашего XML документа ( <InvoiceNum>12345<InvoiceNum> ) будет преобразовано в BGM+380+12345+9+NA', что соответствует записи в левой части таблицы объкта Element ( Name ="InvoiceNum" Value = # ) и BGM+380+#+9+NA' в правой. Если какой либо сегмент содержит информацию из нескольких родственных (Sublin) тагов, то указывается номер вхождения:

Пример: Сегмент NAD содержит информацию из элемента "ConsigneeName" - вхождение #01 и элемента "Addsress" - вхождение #02:

Соответственно информация из элемента "Addsress" извлекается из дочерних элементов ( "City ", "Street" и "Country"), которые имеют свою часть вхождения в сегмент NAD:

При генерации EDI-сообщения, необходимая информация извлекается из значений атрибутов, которые описываются как константы элементов DTD. Каждый элемент, информация из которого имеет вхождение в сегмент сообщения, имеет атрибуты:

EDI-Prefics - информация (статическая часть текста сегмента) предшествующая вхождению переменной; EDI-Suffics - статическая часть текста сегмента после вхождения переменной.

Так для тага <InvoiceNum> атрибутом является:

EDI-Prefics - "BGM+380+"

EDI-Suffics - "+9+NA' ".

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

Ниже представлена часть таблицы определения данных, которая иллюстрирует основы построения DTD для XML/EDI.

<!DOCTYPE Invoice [ <!ENTITY InvoiceNum (#PCDATA) > <!ATTLIST InvoiceNum EDI-Prefics CDATA #FIXED "BGM+380+" EDI-Suffics CDATA #FIXED "+9+NA'" Title CDATA"INVOICE" Size NUMBER #FIXED "8" >

<!ENTITY Consignor (ConsignorName, Address) > <!ATTLIST Consignor EDI-Prefics CDATA #FIXED "NAD+SE+++" EDI-Suffics CDATA "#FIXED "'" Title CDATA #FIXED "" Size NUMBER #FIXED "30" >

<!ENTITY ConsignorName (#PCDATA) > <!ATTLIST ConsignorName EDI-Prefics CDATA #FIXED "" EDI-Suffics CDATA "#FIXED "++" Title CDATA #FIXED ""Отправитель" Size NUMBER #FIXED "30" >

<!ENTITY Consignee (ConsigneeName, Address) > <!ATTLIST Consignee EDI-Prefics CDATA #FIXED "NAD+BY+++" EDI-Suffics CDATA "#FIXED "'" Title CDATA #FIXED "" Size NUMBER #FIXED "0" >

<!ENTITY ConsigneeName (#PCDATA) > <!ATTLIST ConsigneeName EDI-Prefics CDATA #FIXED "Отправитель " EDI-Suffics CDATA #FIXED "++" Title CDATA #FIXED "Получатель" Size NUMBER #FIXED "30" >

<!ENTITY Address (Street?,City,ZIP?,Country) > <!ATTLIST Address EDI-Prefics CDATA #FIXED "" EDI-Suffics CDATA #FIXED "'" Title CDATA #FIXED "Адрес" Size NUMBER #FIXED "30" >

<!ENTITY Street (#PCDATA) > <!ATTLIST Street EDI-Prefics CDATA #FIXED "" EDI-Suffics CDATA #FIXED "+'" Title CDATA #FIXED "Улица" Size NUMBER #FIXED "30" >

<!ENTITY City (#PCDATA) > <!ATTLIST City EDI-Prefics CDATA #FIXED "" EDI-Suffics CDATA #FIXED "+'" Title CDATA #FIXED "Город" Size NUMBER #FIXED "30" >

<!ENTITY Zip (#PCDATA) > <!ATTLIST Zip EDI-Prefics CDATA #FIXED "" EDI-Suffics CDATA #FIXED "+'" Title CDATA #FIXED "Индекс" Size NUMBER #FIXED "6" >

<!ENTITY Country (#PCDATA) > <!ATTLIST Country EDI-Prefics CDATA #FIXED "" EDI-Suffics CDATA #FIXED "" Title CDATA #FIXED "Страна" Size NUMBER #FIXED "3" > ]>

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

Хотелось бы поблагодарить коллектив , проверивший "на своей шкуре" все описываемые действия. Если у Вас возникнут вопросы в процессе выполнения инструкций в статье, буду рад ответить. Мой адрес электронной почты . Пожалуйста, описывайте свою проблему подробнее! Комментарии бесплатные, но весьма краткие. Компьютерная революция не ждет никого, в том числе и меня...

Окончание работы

Для нормального завершения работы сессии нужно выполнить logout на удаленной машине. (Обычно Ctrl+D) Чтобы закончить работу с NCSA Telnet следует выполнить logout для всех сессий.

Если ломается удаленная машина и/или подвисает (не отвечает) сессия, то по Alt+X - будет произведена попытка закрыть сессию с сохранением остальных сессий.

Ctrl+Shift+F3 - принудительное прерывание работы всей программы NCSA Telnet. Рекомендуется использовать только в самом крайнем случае, когда все остальные средства исчерпаны, т.к. ведет к закрытию всех сессий с возможной потерей данных. (* Это средство, на самом деле, тоже не всегда помогает, чаще спасает только Ctrl+Alt+Del)

Ctrl+C или Ctrl+Break - не имеют эффекта при попытке спасти сессию.

Описание тегов (переведено из документации Motorola SDK) :

Деки.

Дека определяется элементом wml

<?xml version="1.0"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN""http://www.wapforum.com/DTD/wml_1.1.xml"> <wml> <card> <p>Hello World!</p> </card> </wml>

Органы управления (controls)

ActiveX - это ответ Microsoft на вопрос, на который ответов уже предложено едва ли не больше, чем хотелось бы: как преодолеть ограничения языка HTML и сделать Web-страницу не менее разнообразно оформленной и интерактивной, чем какое-нибудь мультимедийное приложение? Решение, предложенное корпорацией Netscape, известно довольно давно: это, с одной стороны, апплеты (небольшие специализированные программы на языке Java), а с другой - подключаемые модули (plug-ins), которые, будучи почти самостоятельными приложениями, способны реализовать любую функцию интерфейса или обработки данных.

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

От модулей Netscape Navigator органы управления ActiveX отличаются более узкой и дробной специализацией, меньшими размерами передаваемых по сети файлов, а главное - полностью автоматизированной установкой. Встретив в HTML ссылку на некий орган управления, броузер сначала проверяет, нет ли его уже на компьютере пользователя (то есть не использовался ли он раньше). Если орган управления найден, броузер запускает его, передает ему нужные для работы данные и, таким образом, обходится без лишнего выхода в сеть.

Если же этого компонента на компьютере еще нет, броузер обращается к серверу, адрес которого указан в теле HTML-документа, и, перекачав с него файл, устанавливает и регистрирует новый орган управления в Windows. В принципе, после этого органом управления может пользоваться не только броузер, но и любое приложение, способное работать с так называемыми "нестандартными органами управления OLE" ("OLE Custom Controls", OCX).

Однако самые важные достоинства и недостатки органов управления ActiveX нагляднее всего показывает сравнение их с Java-апплетами. Первый бросающийся в глаза недостаток всей системы ActiveX - ее жесткая привязка к конкретной операционной системе (Windows 95/NT). Поскольку значительную часть поддержки ActiveX и взаимодействия компонентов OLE обеспечивает сама операционная система, то перенести все это хозяйство, к примеру, на UNIX будет очень и очень непросто.

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

Как известно, разработчики языка Java решили эту проблему, заключив апплеты в непроницаемую капсулу виртуальной машины, из которой они не смогут нанести никакого вреда компьютеру. Фирма Microsoft пошла по другому пути и разработала систему электронных подписей, которыми разработчики должны удостоверять подлинность всех созданных ими компонентов ActiveX. Предполагается, что каждый пользователь составит для себя список тех компаний, которым он согласен доверять с закрытыми глазами, после чего броузер будет устанавливать на компьютер и запускать органы управления этих фирм без лишних вопросов.

Если же броузеру встретится ссылка на файл, подписанный неизвестно кем или не подписанный вообще, то решение о том, брать ли на себя риск связываться с этим компонентом, придется принимать пользователю (рис. 1).

Рисунок 1. Этот орган управления не подписан. Что одержит верх - любопытство или осторожность?

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

Справедливость, однако, требует признать, что система ActiveX и реализованный в ней механизм безопасности кое в чем заметно удобнее использования языка Java. Во-первых, отсутствие защитной оболочки виртуальной машины позволяет расширить функциональность компонентов ActiveX - им доступен такой прямой и эффективный контроль над компьютером, о котором Java-апплеты не могут и мечтать. Но главный плюс технологии ActiveX, благодаря которому она так резко стартовала и так быстро завоевала признание, - это то, что программистам, желающим заняться разработкой компонентов ActiveX, почти не приходится переучиваться. OCX-модули впервые появились вместе с версией 4.0 языка Visual Basic и очень многое унаследовали от еще более старого стандарта VBX ("Visual Basic Controls"). Именно органы управления VBX в свое время и стимулировали развитие целой индустрии программных модулей, которые любой программист может купить и использовать в своих разработках. Переделать же OCX-модуль в компонент ActiveX даже проще, чем старый VBX в OCX.

Более того - в броузере Internet Explorer технология ActiveX является не одним из усовершенствований, а буквально фундаментом всей программы. При запуске броузера управление получает миниатюрный контейнер, сразу же вызывающий специальный OCX-модуль, - в котором, собственно, и заключены все функции броузера. Любой программист может, таким образом, без труда встроить в свою программу полнофункциональный броузер WWW, написав всего лишь небольшую функцию для вызова этого модуля и обмена данными с ним. Отдельные функциональные блоки броузера - виртуальная машина Java, интерпретатор HTML и даже сам блок взаимодействия с органами управления ActiveX, - все они реализованы в виде OCX-модулей. Как заметил один программист, "Похоже, ребята в Microsoft сейчас только тем и занимаются, что берут все свои программы по очереди и распиливают их на OLE-компоненты".

Основной подтип 'Application/Octet-Stream'

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

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

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

Дополнительный параметр, "conversions", определенный в [RFC-1341], был исключен в последствии.

В RFC 1341 также определен параметр "NAME", указывающего имя файла, которое должно быть использовано при сохранении данных на диск. Но он опять же был отменен в ожидании введения отдельного поля заголовка Content-Disposition, которое будет определено в ближайшем будущем.

Рекомендуемое действие для почтовой программы, получившей почту типа application/octet-stream, - просто предложить записать данные в файл без какого-либо преобразования, или. возможно, произвести его в соответствии с указанием пользователя.

Для уменьшения опасности передачи вирусных и других намеренно разрушающих систему программ по почте, строго рекомендуется, чтобы почтовая программа получателя не производила запуск программы, заданной в параметре поля "Content-Type" (например, в параметре "interpreter="), использующей в качестве входных данных тело письма.

Основной подтип 'message/rfc822'

Этот подтип указывает, что тело письма содержит вложенное письмо в стандарте RFC 822, однако, в отличие от заголовка RFC 822 верхнего уровня, для каждой части, являющейся письмом RFC 822, не требуется наличия полей "From", "Subject" и, по крайней мере, одного поля "To".

Не смотря на использование числа "822", тело, имеющее подтип 'message/rfc822', может включать дополнительную информацию в соответствии со стандартом MIME. Другими словами, письмо 'message/rfc822' может быть MIME-письмом.

Основной подтип "multipart/mixed"

Это основной подтип для типа 'multipart', он предназначен для случая, когда части письма взаимонезависимы. Любые новые подтипы, неизвестные почтовой программе, должны быть истолкованы аналогично подтипу 'mixed'.

Основы XML и объектная модель представления данных

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

В начале февраля 1998 г международная организация W3C утвердила спецификацию "Extensible Markup Language(XML) 1.0". Уже сегодня появляются новые языки, созданные на основе XML. Возникают многочисленные Web-сервера, использующие и технологию XML для организации хранящейся на них информации.

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

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

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

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

Сегодня на рассмотрение W3C предложена спецификация нового языка запросов к базам данных XQL. Информация, содержащаяся в XML-документах, может изменяться, передаваться на машину клиента и обновляться по частям. Разрабатываемые спецификации XLink и Xpointer позволятют ссылаться на отдельные элементы документа, c учетом их вложенности и значений атрибутов. Использование стилевых таблиц (XSL) позволяет обеспечить независимое от конкретного устройства вывода отображение XML- документов и фильтрацию данных.

Тэги языка кодируются и выделяются относительно основного содержимого документа и служат в качестве инструкций для программы, производящей действия над содержимым документа на стороне клиента.

Исторически сложилось таким образом, что в системах для обозначения этих команд использовались символы "<" и ">", внутри которых помещались названия инструкций и их параметры. Сейчас такой способ обозначения тэгов является стандартным.

Например, для создания элемента Ivanov в имене заказчика используется тэг <CustumerName>. В программе это выглядит следующим образом: <CustumerName> Ivanov </CustumerName>

Определения тэгов может легко расширяться. Так для указания более полных реквизитов заказчика можно определить тег <Custumer>, в который включено не только имя, телефон заказчика, но и адрес компании.

<Custumer> <CustumerName> Ivanov </CustumerName> <phone>312-12-13<phone> <Company>Bussines Trade Consulti</Company> </Custumer>

Можно создать массив заказчиков, определив тег <Custumers>:

<Custumers> <Custumer> <CustumerName> Ivanov </CustumerName> <phone>312-12-13<phone> <Company>Bussines Trade Consulti</Company> </Custumer> <Custumer> <CustumerName> Petrov </CustumerName> <phone>315-15-16<phone> <Company> Trade Forest Company</Company> </Custumer> <Custumer> ...... </Custumer> </Custumers>

Из приведенного примера видно, что XML - документы подлежат четкой структуризации и имеют четкую иерархическую структуру следования элементов. Элементы имеют своих родителей - корневые элементы и наследников - дочерние элементы.

Документ XML состоит из элементов. Элемент - это структурная единица XML- документа. Заключая данные об имени заказчика в тэги <CustumerName> </CustumerName>, XML-процессор определит как элемент. Содержимым элемента CustumerName является значение. В нашем примере имеется два значения (Ivanov и Petrov) элемента CustumerName.

Контроль за правильностью использования порядка использования элементов осуществляется при помощи специального набора правил, называемых DTD (Document Type Definition)- описаниями, которые используются программой клиента при анализе документа.

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

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

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

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

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

<container Type="20f">123456</container > двадцати футофый контейнер <container Type ="30f ">654321</container> тридцати футофый контейнер

Просмотр XML документов осуществляется специальной программой анализатором. На сегодняшний день разработано около десятка подобных анализаторов. В своем новом броузере Internet Explorer 5 фирма Microsoft уже предусмотрела анализ XML документов.

Анализ документа в Internet Explorer 5 осуществляется тремя вариантами: просмотр аналогично HTML документу, форматирование документа с использованием специальных стилевых таблиц - XSL и анализ с помощью сценариев, написанных на Java Script ил VBScript.

Поиск нужного элемента или поддерева осуществляется при помощи XQL запроса. XQL является частью XML и переволится как язык запросов для XML (XML Query Language). Идет дисскусия об утверждении языка запросов в качестве общепринятого стандарта, который может заменить SQL.

Синтаксис языка запросов очень гибок и позволяет осуществлять поиск элемента как по названию, значению атрибутов, содержанию, так и учитывать вложенность и положение в дереве элементов. При помощи запросов мы можем выделять из общего дерева необходимые нам элементы и применять к ним необходимые инструкции. Запрос возможно применять как к самому XML документу, так и к ссылкам URL.

Язык запросов напоминает обычный способ определения пути к ресурсу- список узлов дерева, разделенных символом "/". Для указания на текущий элемент используется символ "." , на родительский - "..", для выделения всех дочерних элементов - символ "*", для выделения элемента, расположенного просто "ниже" по дереву(не важно на каком уровне вложенности) - "//".

Условие на значение в запросе должно заключаться в символы "[" и "]". Для выбора значения атрибута в условии указывается символ @.

Примеры простых XQL шаблонов:

"/Customer "	корневой элемент
"Customers/"	возвращает дочерние элементы для элемента Customers
"Customers //"	список всех элементов, вложенных в Customers
"container[@Type]"	список элементов container, в котором определен атрибут Type
"container[@Type =20f]"	поиск всех двадцатифутовых контейнеров, т.е. элементов container, в котором значение атрибута Type равно "20f"
"Customers[address]"	список элементов Customers, которые содержат хотя бы один элемент address, выражение в квадратных скобках может быть составным.

Как мы видим, XML документ в отличие от EDIFACT сообщения позволяет более наглядно представить объектную модель данных. Использование языка описания XML запросов - XQL позволяет адекватно формализовать любой из существующих "бизнес" запросов (оформленных в виде стандартных документов) для информационных систем.

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

Экспериментальные значения поля 'Content-Type'

Электронная доставка отчетов

Как проверить

Как устанавливать

КОЛЛЕКТИВНАЯ МУДРОСТЬ

определяют массив названий групп,

Концепция проекта

Конфигурация

Кратко о PERL-модулях от Active State

Листинг:

Литература

Литература

Local или Remote echo mode

Логическая структура документа

Машины, с которыми осуществляется связь

Этот алгоритм разработан для представления

Механизм конвертации "Quoted-Printable"

Меню параметров NCSA Telnet

Microsoft + Internet = ActiveX

Мифы и реальности XML

Модель объектов JavaScript

Моделирование Элементов данных для Бизнес объектов.

Моделирование Web и запросы

Multipart: общий синтаксис

На примере прогнозов погоды с Yahoo.com

На распутье

НАЗЫВАТЬ ВЕЩИ СВОИМИ ИМЕНАМИ

NCSA Telnet

NCSA утилиты

Некоторые примеры синтаксиса языка Curl.

Необязательное поле Content-Description

Необязательное поле Content-ID

Новая схема

Новые Технологии распространения информации

в тех случаях, когда организации

Общая информация о работе с NCSA Telnet

Обзор стандарта UN/EDIFACT

Обзор технологий безопасности.

Одноступенчатое формирование XML-документа

Оглавление

Окончание работы

Описание тегов (переведено из документации Motorola SDK) :

Органы управления (controls)

Основной подтип 'Application/Octet-Stream'

Основной подтип 'message/rfc822'

Основной подтип "multipart/mixed"

Основы XML и объектная модель представления данных