Вопросы к разработчикам новой системы оплаты проезда и краш-тест устройства. Что внутри валидатора? Вопросы к разработчикам новой системы оплаты проезда и краш-тест устройства Зачем он нужен

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

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

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

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

Существуют следующие стандарты DOCTYPE:

  • HTML> - соответствует последнему принятому стандарту – HTML5 .
  • - DOCTYPE для стандарта HTML 4.01 Strict (строгий );
  • - DOCTYPE для стандарта HTML 4.01 Transitional (переходный );
  • DOCTYPE HTML PUBLIC “-// W3 C// DTD HTML 4.01 Frameset// EN” http:// www. w3. org/ TR/ html4/ frameset. dtd> - DOCTYPE для стандарта HTML 4.01 Frameset (с фреймами);
  • DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd> - DOCTYPE для стандарта XHTML 1.0 Strict (строгий );
  • - DOCTYPE для стандарта XHTML 1.0 Transitional (переходный );
  • - DOCTYPE для стандарта XHTML 1.0 Frameset (с фреймами );
  • - DOCTYPE для стандарта XHTML 1.1.

Примечание: Как Вы уже заметили, первый в списке DOCTYPE для стандарта HTML5 имеет самую простую запись. Каждый HTML-документ должен начинаться с указания DOCTYPE. Если этого не сделать, то различные браузеры будут отображать страницу по-разному. Впринципе, на работоспособность это не повлияет, но вот визуальная составляющая может пострадать.

Ошибки в коде могут не влиять на отображение страниц. Например, проверки известного бесплатного хостинга Ucoz практически всегда выявляют ошибки. Это не мешает правильно отображать элементы, и часто появляется при компилировании страниц средствами PHP интерпретатора. Большинство технических ошибок в таком случае не критичны, и могут только незначительно замедлить работу сайта.

Основным «подконтрольным» элементом служат именно HTML страницы, хотя валидность каскадных таблиц CSS и RSS-лент также может проверяться. Но не стоит забывать, что валидность – это только соответствие требованиям стандарта. Если сравнивать с реальной жизнью, то валидатор проверит, является ли созданный Вами продукт транспортным средством. А будет это велосипед с реактивным ускорителем или асфальтоукладочный каток с педальным приводом – ему все равно. Поэтому валидность кода еще не означает «правильность» создания страницы или элемента, вернее – не значит, что Вы увидите именно то, что хотели.

Проверка может проводиться различными средствами, но все они ссылаются на сайты стандартизаторов, т.е W3C сервисов. Контроль проводится по трем основным форматам (HTML, CSS, RSS), но в любом случае сначала необходимо проверить корректность HTML. Проверке подлежит, прежде всего, синтаксис документа с точки зрения технических параметров.

Сегодня большая часть сервисов предлагает проверку валидности кода онлайн, при этом не обязательно вносить код на страницу проверки, а достаточно указать лишь адрес проверяемого сайта. Предлагаемые «загружаемые» сервисы в любом случае ссылаются на сервисы W3C, проверяя введенный код на корректность и соответствие правилам. Одним из таких сайтов является http://validator.w3.org . Он позволяет проверить корректность сайта в Интернете, HTML-файла, либо самого HTML-кода. Существуют приложения к браузерам, позволяющие проверять код «на лету», в частности такое дополнение(Web Developer ) разработано для Mozilla Firefox в качестве встроенного инструмента для проверки корректности написанного кода. Вы устанавливаете дополнение, после чего появляется дополнительная панель в окне браузера. Открываете сайт или страничку и жмете на панели Tools- Validate HTML (CSS и др.) После Вас перекинет на вышеуказанную страничку, но с заполненными полями.

Разработчики системы "умного проезда" (автоматизированной системы оплаты и контроля проезда или АСОКП) в коммунальном пассажирском транспорте утверждают: те возможности, которые мы видим сегодня, - только вершина айсберга. Недочеты системы вскоре будут исправлены, а из тестового режима в рабочий, согласно планам, система выйдет к августу .


На наших глазах было проведено тестирование надежности валидатора.

Внимание! У вас отключен JavaScript, ваш браузер не поддерживает HTML5, или установлена старая версия проигрывателя Adobe Flash Player.


Открыть/cкачать видео (2.49 МБ)

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




Редакция предупреждает - попытка повторения подобного опыта в транспортном средстве обойдется вам очень дорого.

О проекте электронной оплаты проезда IT.TUT.BY рассказал директор технического отделения IBA , руководитель проекта по программной части.


Долго ли разрабатывались системы электронной оплаты проезда? Какой у компании опыт в подобных проектах?

Непосредственно проектом электронной оплаты проезда мы занимаемся уже более трех лет. Другого рода системы по продаже билетов (к примеру, через банковские устройства) разрабатывались и ранее. Таким образом, системами оплаты проезда на транспорте IBA занимается более пяти лет. Вообще же в направлении создания систем самообслуживания компания работает более 10 лет.

Даже тогда, когда в Беларуси банковские карточки практически совсем не были распространены, мы создавали системы автоматизированной оплаты. Тогда было много скепсиса: "А оно не сломается?", "Как тут платить?" … но прошло 10 лет, и сейчас банковские платежно-справочные терминалы де-факто являются стандартном, в их удобстве не сомневаются. Уверен, система автоматизированной оплаты проезда уже скоро станет привычной и неотъемлемой частью нашей жизни.

Надолго ли прописана "дорожная карта" проекта, какие еще сервисы будут появляться?

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






Прототип терминала выдачи и пополнения бесконтактных карт

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

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

Вопрос из области фантастики: если возможно объединить в одну карточку проездной на все виды транспорта по всей стране, то, быть может, можно в эту же карточку добавить платежные возможности и даже электронный паспорт? Увидим ли мы такое через 5-10-20 лет?

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

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

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

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


Будет ли когда-нибудь применяться технология NFC, позволяющая проводить оплату с телефона?

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

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

Но пока используются карты Mifare и технология RFID. Что значат эти слова?

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

Mifare - одна из самых популярных в мире технологий для систем бесконтактной оплаты проезда. Недостатки старой версии Mifare Classic были изучены, и недавно была представлена новая версия - Mifare Plus, которую мы и используем. Версия Plus защищена от копирования и подделок, данные шифруются сложными алгоритмами. Разработчики стандарта, с которыми мы тесно сотрудничаем, говорят, что IBA Group одной из первых компаний в мире внедрила систему с максимальным уровнем безопасности технологии Mifare Plus.



Почему сейчас параллельно используется распечатка на талончике и RFID-валидатор для проездных? Возможно ли отказаться от талончиков или распечатывать их прямо на терминале?

Организация оплаты разовой поездки - это проблема любой транспортной системы. На момент разработки проекта около 40% поездок являются разовыми. Поэтому наличие отдельного способа оплаты для разовых поездок - это обязательное требование.

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

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

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

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

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


Фото: Снежана Инанец, из архива TUT.BY

То есть больше людей захотят покупать карты-проездные вместо разовых талонов? Что для этого нужно сделать?

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

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

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

Да, именно так. Карточки позволят выбирать абонентский план, более правильно рассчитывать свои затраты. Но сравнивать карточку Mifare, которую мы используем, с сим-картой некорректно. Скорее она как кошелек, поскольку тарифы хранятся прямо на карточке. Ждать ничего не надо, как только пассажир пополнил карту, он может оплатить проезд.

Но даже гибкие тарифы не снимут вопросы про "мне только одну остановку". Рассматривался ли вариант с чем-то вроде турникета на входе, как это иногда делается за рубежом?

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



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

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

И тарифы, и поддержка NFC или сенсорных кнопок могут прийти в каждую машину в течение одного дня - как только транспортное средство подключится к сети, на него "зальется" прошивка по каналам мобильной связи. Кстати, прошивка "весит" совсем немного, это не десятки мегабайт, тут не Windows и не Linux. В месяц на одно транспортное средство с учетом ежедневной передачи данных по навигации и оплате, а также нескольких больших обновлений, требуется не более 60 Мб.

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


Высказывалось также недовольство из-за сообщений только на одном языке...

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


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

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

О "железе", технической реализации "умного проезда" мы расспросили Сергея Сягло , директора ОДО "Проток люкс", предприятия, входящего в IBA Group, руководителя проекта по аппаратной части.

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

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

В электронном компостере содержится компактный матричный принтер компании R&G, специально разработанный для жестких условий эксплуатации в общественном транспорте. Решение в их пользу было принято из-за их огромного опыта и экономической нецелесообразности собственной разработки. Разработка программного обеспечения, а также интеграционные работы с АСОКП производились в Беларуси.

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



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

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

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

HTML-стандарт однозначно определяет основную структуру Web-документа. Язык HTML является подмножеством языка описания документов SGML (Structured Generalized Markup Language), таким образом, html-документ - это текстовый документ, состоящий из html-кодов и основного текста документа. Для просмотра этого документа необходим WEB-браузер - специальная программа для интерпретации и корректного отображения страницы на экране.

Что такое стандарт HTML?

* HTML был первоначально разработан Tim Berners-Lee и популяризован браузером Mosaic, разработанным NCSA. В течение 90х гг. он буквально расцвёл в связи с бурным развитием Web. Было время, когда веб-разработчики вынуждены были использовать html-стандарт 2.0 (был разработан под эгидой Internet Engineering Task Force (IETF) для упорядочения общепринятых положений в конце 1994 года), который поддерживал только форматирование текста и встраивание простой графики.
* В 1995 году были опубликованы некоторые предложения по расширенному стандарту HTML 3.0, которые стали использоваться как неофициальные HTML-рекомендации, воплотившиеся в различных браузерах.
* В мае 1996 года появился стандарт версии 3.2. За стандарт несет ответственность организация - WWW-Консорциум (W3C - world wide web consortium), она представляет собой объединение представителей промышленности и науки.
* 18 декабря 1997 года вышел первый релиз W3C спецификации на HTML 4.0. Второй выпуск (24 апреля 1998 года) содержал некоторые редакторские корректировки.
* 24 Декабря 1999 года вышел стандарт HTML 4.01 - исправлены некоторые ошибки предыдущего стандарта – 4.0
* Наличие стандарта предполагает необходимость в специальной программе (собственно VALIDATOR), которая проверяет наличие в HTML-документе нарушение спецификаций, согласно которой составлен документ, если эти нарушения там действительно есть.

Что такое Валидатор?
определение:
Validator: a conforming SGML parser that can find and report a reportable markup error if (and only if) one exists.
Валидатор: анализатор соответствия стандарту SGML, который находит и сообщает о подлежащей отчету ошибке разметки, если (и только если) она существует.

ISO 8896, параграф 15.4.

Таким образом HTML-система является валидирующей HTML-системой, если
1) она является валидирующим SGML-анализатором согласно ISO 8879, п.15.4;
2) она способна обрабатывать любой согласующийся с HTML документ;
3) она находит и сообщает об ошибке в HTML, если она существует;
4) она не сообщает об ошибке в HTML, если она не существует.

ISO/IEC 15445:2000/DCOR 1:2001(E), параграф 2.2.

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

Два самых распространённых браузера для Windows отображают страницы примерно одинаково, отличаясь лишь в таких деталях, как поля и отступы. Браузеры для Macintosh или *никсов обычно отличаются от этих двух более глобально. Очевидная выгода наличия стандарта в том, что проконтролировать одну спецификацию значительно легче, чем многие браузеры.
цитата:
«...Для людей с проблемами зрения HTML предоставляет многообещающие возможности уравнять их в правах с обычными людьми при использовании базового графического пользовательского интерфейса Windows. Табличная модель HTML включает атрибуты для пометки каждой ячейки, чтобы поддержать высококачественный текст для речевого интерфейса. Эти же атрибуты могут использоваться при поддержке автоматизированного импорта и экспорта данных таблиц в базы данных или электронные таблицы...»

Многие разработчики (преимущественно начинающие веб-дизайнеры) могут не согласиться с необходимостью соответствия кода спецификации: «Валидатор оставляет после себя тоскливые сайты, убивает творчество». Такое мнение возникает от простой лени. Корректный HTML-текст вполне допускает динамику, мультимедийные объекты, использование сценариев и т.д.; просто все эти эффекты можно сделать грамотно, а можно - неграмотно. Надо также помнить, что во всякой творческой области надо сначала изучить правила, а уже потом суметь превзойти их. Кроме того, даже опытные разработчики не застрахованы от ошибок, мы все можем допускать опечатки или забывать закрыть тег. Валидатор способен отследить подобные ошибки и явным образом указать место с некорректным форматированием.

Приведем конкретные примеры ошибок, которые определяются валидатором:

ISO 8896, параграф 15.4.

- неправильно
(Error: start tag was here).

ISO 8896, параграф 15.4.

- правильно.

вставлен текст

- неправильно
(Error: element "P" not allowed here; possible cause is an inline element containing a block-level element)

Вставлен текст

- правильно.

Если вы пришли к тому, что вам необходимо проверить ваш код на соответствие спецификации, прочтите несколько советов:

Где взять валидатор?

Валидатор в форме веб-страницы предлагается на https://validator.w3.org. Он основывается на SP Кларка.

Есть также и валидатор на https://htmlhelp.com/ . Он тоже основывается на SP, хотя и немного изменённом. Авторами декларируется, что он более строг в оценке и объявляет потенциально опасные, хотя и допустимые места (скажем, незакрытый тег с необязательным закрытием). Предлагают исходники валидатора

Доступный подо все платформы бесплатный валидатор можно скачать с сайта Дж. Кларка (https://www.jclark.com/sp/). Вместе с парсером/валидатором в поставке прилагается потоковый нормализатор.

W3C раздаёт исходники валидатора на https://validator.w3.org/, но это, на самом деле, не валидатор. Это лишь адаптация кларковского валидатора к веб-интерфейсу, исполненная на перле. В описании этой адаптации недвусмысленно сказано, что следует иметь на машине кларковский валидатор. Еще ссылки:
· https://ugweb.cs.ualberta.ca/~gerald/validate/
· https://www.webtechs.com/html-val-svc/
· https://www2.imagiware.com/RxHTML/

Можно ли назвать валидатором инструмент из HomeSite – Validate Document?

Разработчики Allaire HomeSite объявляют, что что «…проверяющая программа выпускается ими под названием «валидатор» сугубо из коммерческих соображений…», и настоящий валидатор выпускаться ими не будет.

Программа, идущая в комплекте с HomeSite, нарушает определение валидатора: она находит и показывает ошибки, которые не были допущены, и не находит ошибок, которые были допущены.
Вот пример её неправильных действий:
а)
Реакция: нет реакции.
В действительности, здесь ошибка: не выставлен ALT второго IMG.
б)

Реакция: ошибка.
В действительности, этот тег возможен в рамках XHTML.

Стремление к безупречности - первый признак профессионализма, и нет необходимости ориентироваться на популярные, однако далекие от совершенства html-кода порталы. Возможно, менеджеры подобных сайтов, проанализировав статистику посещений, выяснили, что 99% приходящих пользователей увидят все так, как предполагал дизайнер... Возможно, авторы сайта намеренно исключают из числа своих посетителей пользователей с ограниченными возможностями... однако следует помнить такие понятия, как гуманизм и требования закона. С появлением официального стандарта из-за нарушений спецификации есть опасность попасть в суд по обвинению в недоступности сайта для тех, кто не может использовать «обычный» браузер. Хотя в регионах стран бывшего СНГ законодательство довольно ограничено в этом отношении, в просвещённом мире вопрос решается лучше. Доступность понемногу приобретает силу закона. Валидатор не гарантирует доступности (потому что не может быть заменой здравого смысла), но помогает обеспечить должную меру поддержки всех пользователей.

Удачных сайтов и безупречного кода вам, уважаемые разработчики!

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

Энциклопедичный YouTube

    1 / 2

    ✪ ВЗЛОМ КАРТЫ ТРОЙКА? | БЕСПЛАТНЫЙ ПРОЕЗД В МЕТРО

    ✪ AS A startup company invents a system to validate bus tickets using Google Glass

Субтитры

Валидаторы на транспорте

Москва

Первые турникеты с валидаторами в наземном общественном транспорте Москвы в рамках эксперимента по внедрению автоматизированной системы контроля проезда (АСКП) появились в 2001 году в Зеленоградском административном округе на автобусном маршруте № 16 . К середине 2002 года система была распространена на все зеленоградские автобусные маршруты (муниципального подчинения), а с сентября 2007 года и на весь наземный городской общественный транспорт муниципального подчинения.

Санкт-Петербург

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

К 2011 году большая часть городских автобусов была переведена на новую систему электронного контроля оплаты проезда (СЭКОП). Данная система предусматривает наличие стационарных валидаторов в салоне транспорта на поручнях (от 4 до 9 штук), которые позволяют пассажиру самостоятельно производить оплату проезда (валидацию электронного проездного билета).

В состав СЭКОП входят валидаторы двух типов - простые и информационные. Простые валидаторы имеют светодиодную индикацию, которая информирует пассажира о следующих событиях:

  • Валидатор готов к считыванию электронного проездного билета.
  • Проезд оплачен.
  • Проезд не оплачен (например, истёк срок действия).
  • Электронный проездной билет приложен повторно (проезд на данном рейсе уже оплачен).
  • Валидатор заблокирован контролёром на время проверки оплаты проезда.

Информационные валидаторы имеют дисплей (изготовленный по технологии Органический светодиод), который, помимо индикации событий, аналогичных простому валидатору, может выводить информацию об электронном проездном билете (срок действия, ресурс поездок или баланс в зависимости от типа ЭПБ). Для получения такой информации необходимо сначала оплатить проезд, затем снова приложить билет к информационному валидатору. Валидатор покажет, что билет приложен повторно, и через некоторое время отобразит информацию о ресурсе электронного проездного билета.

Другие города

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

В городе Бийске с 1 июня 2016 года система оплаты проезда через валидатор с помощью транспортной карты, введены электронные проездные карты и билеты во всех трамваях и автобусных маршрутах города.

В городе Барнауле с 1 декабря 2016 года внедрена система оплаты проезда через валидатор с помощью транспортной карты . Электронные проездные билеты принимаются к оплате во всех трамваях, троллейбусах и автобусных маршрутах города.

Примечания

  1. Скребнева, Елена Всех - за турникет (неопр.) . Российская газета (Центральный выпуск) № 3272 (11 августа 2003).
  2. По Москве поехали государственные маршрутки (неопр.) . Архивировано 16 февраля 2012 года.
  3. В городе уволят всех кондукторов? (неопр.) . Архивировано 16 февраля 2012 года.
  4. В Петербурге уволят всех кондукторов (неопр.) . Архивировано 16 февраля 2012 года.
  5. На улицы Петербурга вышли первые пассажирские автобусы, оборудованные спутниковой навигацией и «валидаторами». (неопр.) . Архивировано 16 февраля 2012 года.
  6. Автобусы обзаводятся электроникой (неопр.) .