В этой статье написано несколько слов о важном разграничении, которое заслуживает большей оценки, поскольку оно лежит в основе нескольких текущих дискуссий по совместимости. То, что я здесь расскажу, хорошо известно любому инженеру, хотя я думаю, что почти каждый может понять суть этого.
Во-первых, давайте рассмотрим основы.
Форматы определяют, каким образом информация кодируется. Например, HTML-это стандартный формат для описания веб-страниц.
Протоколы определяют, как закодированная информация передается из одного конца в другой. Например, HTTP – это стандартный протокол для загрузки веб-страниц с веб-серверов в веб-браузеры.
Есть и другие пары формат/протокол, таких как MIME и SMTP для электронной почты. Когда мы говорим о “веб-стандартах” мы говорим о форматах (часто описываемые рекомендациями W3C) и протоколах (часто описанными в IETF RFCs).
Экземпляру данных, который соответствует определенной стандартной форме может быть дано любое количество терминов: веб-страница, документ, изображение, видео и т. д. согласно базовому стандарту. Экземпляр формата данных, битов и байтов, которые вы можете сохранить на жесткий диск, записать на компакт-диск, отправить по электронной почте и т. д. Данные в формате стойкие и имеют статическое представление.
Но что такое протокол? Это транзакция. Это эфемерно. Вы не можете легко сохранить экземпляр HTTP или SMTP на своем жестком диске или отправить его кому-то другому. Протокол – это сложный набор запросов и ответов, и имеет часто обсуждаемые возможности, которые сообщают о возможности передачи данных.
Когда дело доходит до функциональной совместимости, существует ключевое различие между форматами и протоколами. Ключевым моментом является то, что протокол обычно включает в себя согласование деталей связи между двумя идентифицируемыми сторонами, каждая из которых может указывать на свои возможности и предпочтения, а также соответствовать возможностям самого канала передачи данных. Программное обеспечение, работающее на каждой конечной точке транзакции, может адаптироваться как часть этого согласования.
Вы уже знакомы с модемами, где эта процедура проявляет себя всякий раз, когда вы подключены к удаленному узлу. Но хотя вы не слышите и не видите всё это, эти переговоры всё-таки происходят сегодня с протоколами, за кулисами.
Например, когда вы запрашиваете веб-страницу, ваш клиент договаривается с помощью всяких параметров с веб-сервером, в том числе о размере пакета и таймингах (на уровне TCP/IP) для проверки подлинности, языка, наборах символов и кэше предпочтения (на http уровне). Это согласование возможностей имеет важное значение для обработки многообразий и разницы веб-серверов и веб-клиентов на сегодняшний день.
С протоколом, у вас есть две технических конечные точки коммуникации и согласование параметров обмена данными. Другими словами, у вас есть программное обеспечение на обоих концах связи которое может применить логику, чтобы адаптироваться к потребностям другой конечной точки и возможностям базового канала связи.
Но, когда дело доходит до формата, вещи становятся разными.
Давайте будем использовать текстовый процессор для документов Word в качестве примера и как экземпляр формата. Я автор документа, и когда я отправляю его по электронной почте, как вложение на мой блог, записанную на компакт-диск конференцию, размещенный на сервере документ или любой другой. Я понятия не имею, кто будет на приёмном конце, какое программное обеспечение они будут использовать. Это может быть Microsoft Office, но они могут также использовать документы в OpenOffice Google, wordperfect, в abiword, и т. д. Я, как автор документа, имею возможность направлять документ на принимающую сторону, поскольку их личности и возможности неизвестны и в целом не распознаваемые.
Поскольку документ не является исполняемой логикой, он не может адаптироваться к особенностям различных конечных точек. Документ – это статическое. Когда приходит время, чтобы интерпретировать этот документ, Вы не видите двух точек поставщика адаптации и переговоров. Вы видите только одну часть программного обеспечения, принимающего заявки участника, и они должны интерпретировать статический экземпляр данных в заданном формате.
Иными словами, в форматах документов, нет динамического согласования, потому что в то время, когда вы записали документ, Вы не представляете, какие приложения будут использоваться для его прочтения. И хотя приложение, которое считывает документ может знать личность письменного заявления (через метаданные, хранимые в документе, например), оно не имеет возможности договориться с написанием заявления, поскольку это заявление не присутствует когда документ загружается.
Всё достаточно просто. Но, если перепутать понимание этого различия, то это может привести вас к сумбурному рассуждению о совместимости и как это достигается.
Хотя это не идеал, но Майкрософт имеет раскрытие всех этих подробностей, как именно они реализуют различные собственные протоколы и даже их причудливые реализации стандартных протоколов, это может позволить 3-м лицам получить код на все эти детали. Если раскрытие своевременное, полное и точное, то эта информация может быть полезной.
Но, нет никакой информации от Microsoft о том, как они интерпретируют стандарт ОДФ. Мы видим, что сегодня, Office 2007 с пакетом обновления 2, где исключали ОДФ формул электронных таблиц. Имея официальную документацию этого факта от Microsoft, в виде “замечание” не поможет совместимости. Почему? Потому что когда я создаю документ в формате odf, я не знаю, кто читатель. Это может быть пользователь Microsoft офис. Но, возможно, это не так. Это очень хорошо могут прочитать разные пользователи, используя различные программы. Я не могу адаптировать документ к совместимости различных реализаций ОДФ.
Когда вы имеете дело с форматами взаимодействия которые достигаются путём объединения единой интерпретации формата. Имея хорошо документированный формат, но расхождения в толкованиях не улучшат взаимодействие. Раскрытие закидонов недостаточно. Раскрытие предполагает обмен документом, в котором есть заявление писателя, и он знает, что читатель будет использовать Microsoft Office и только Microsoft Office и поэтому писатель может приспособиться к закидонам компании Microsoft. То есть логика монополиста. Взаимодействие с конкуренцией приходит только тогда, когда все разработчики сходятся в интерпретации формата. Когда это произойдет, мы не будем нуждаться в информации. Мы просто будем следовать стандарту.