Исповедь системного администратора (многа букаф, мат)

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

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

 

в общем, есть сторонники динамической типизации, есть строгой статической, а я - сторонник мягкой статической

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

 

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

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

 

видится мне, что это проблема того же уровня, что и ввод/фильтрация телефонного номера - это когда жёстко требуют вводить "именно вот так и никак иначе"
ох, уж сколько виртуальных вуду-копий было втыкано во фронтендеров...
потом, всё-таки, разум восторжествовал, и в большинстве случаев теперь - вводи чо хочешь, но только чтоб не всякую херь типа буковок, спец-символов и null - обойдись типа набором [-+._ 0-9] -- и, внезапно(!), проблема растворилась! да и в других фильтрах теперь не особо обращают внимание на "несоответствие телефонного номера какому-то там формату".

это как на пустом месте сотворить формат, и потом жосско требовать его исполнения, а за неисполнение - бить по рукам.

я не против проверок вообще. я за применение их в нужном месте и с нужной "степенью нажатия"

 

ну или я путаю, или у тебя подход с дырой в безопасности, размером с Манхэттен)
хинт: человек сдает данные, и подписывается под ними. именно такими.
а тут прямой тезис вида "ну ты чот там косячнул, мы ща как нам надо починим"

 

Бюрократия на марше.

 

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

 

ну, специалистом по безопасности я не был никогда несколько хромает этот вопрос у меня. пользуюсь "готовыми решениями" и разными шаблонами.
однако, что такое "подпись" - понимаю - и как хэш, и как gpg, и как подписанный известным CA сертификат.
и если чел сдал данные с <int_value>123 345 </int_value>, и подписался под ними, а я интерпретировал это поле как целое 123345 - то найди мне судью или эксперта (поверх валидатора), который усомнится в моей интерпретации?

p.s.
другое дело, если полученное потом будет обрабатываться не только нами, но и делегироваться на другой уровень... повторная правка "где-то там наверху", конечно, лишней будет. поэтому тут, конечно, лучше сразу обвалидироваться.
ну дык это и не тот случай, о котором разговор зашёл. вроде бы.

 

Есть языки со строгой типизаций. А есть всякое говнище навроде жабаскрипта с очень низким порогом вхождения.
Языки с самой тиранской и развитой системой типов это садо-мазо на этапе компиляции. Зато если компилятор пропустил программу - то шанс что в ней остались какие то ошибки меньше одного процента.
Но это не всем нравится. Сторонники "индийского подхода" считают что главное чтобы заработало и не упало. А то, что заработавшая программа правильно обрабатывает только 1% от всех вариантов использования - это проблема пользователя. Опять таки, в Индокитае 3 млрд населения, будет кому фиксить баги и на каждый пофиксенный сажать два новых...

 

а усомнится)
например если нужен СНИЛС, у которого всратый формат вида сам знаешь какого, если быть точным в передаче.
тебе же принесли 123-456-789 00, а не 12345678900. и в базе СРФ/ПФР, соответственно...
и не мог тебе гражданин принести 12345678900, потому что у него на зелененькой карточке иначе. не подписывался гражданин под твоей творческой переработкой.
или дату оно хочет вида 2023-10-27, а ты сунешь 27.10.23...

а отдельный цирк начинается с иносратыми гражданАми...

 

и ещё, кстати.
я выше согласился - мол, если надо передавать тот хмл на обработку в другие отделы или как-то хранить, при том, что отправляющий подписал отправление, то ...
так вот - одна мысля давно посещала меня - а какого хера, вообще, подписывается нечто (текстовое) _с_пробелами_?
не, для чтения (человеком или машиной), конечно, нужно отделять слова друг от дружки. но так как _уже_принято_ де-факто, что часто балбесы вставляют по два или несколько пробелов между словами, а то и несколько пустых строк (переводами строки) разбавляют текст. зачем учитывать их при составлении "отпечатка" текста?
как по мне - при составлении фингерпринта нужно освобождать входной файл от пробельных символов и переводов строк. и тогда (внезапно!) и проблема с передачей далее подписанного (и обработанного нами) файлика, где затесалось `<int_val>12 234 </int_val>` не будет ...

 

это всё верно, коли речь о программировании
а мы сейчас - про разбор входного xml, где всё изначально - текст, который нужно "отсканировать scanf-ом" (или отвалидировать).
(ed: пардон, в подчёркнутом я имел в виду "разбор значений тегов", <tagname>tag_value</tagname>)

 

А парсинг xml чем то идеологически отличается от парсинга языка программирования?

 

речь не про парсинг всего xml, речь про парсинг значений в тегах.
парсинг первого порядка - разборать по тегам.
парсинг второго порядка - отсканировать (из строки) и валидировать значения тегов <tagname>THIS_TO_SCAN_AND_VALIDATE</tagname>.
в xml не нужно производить вычисления значений тегов (несоклько операндов, присваивание), как это делается в ЯПе. стало быть, похожесть парсинга xml и ЯП - только в сканировании строковых токенов (если я тут с терминами не напутал).

 

"mаil.ru" - всё?

 

фсмысле?

 

ниработаит
(через РТ вообще сайт не находит, через "других провайдеров" - сайт открывается, но сервисы не работают)

 

У меня все вроде норм, через мтс и через локального провайдера, и почта и облако с бэкапами открываются.

 

Единственная проблема в том, что хмл пишут руками хотя он для этого не особо предназначался. Если его пишут не руками, то будьте добры, сделайте так как написано - без самодеятельности. И во многих ситуациях должно быть только два варианта - однозначность чтения хмл или отказ от всего файла, в случае когда такой однозначности нет. Представь, что пришлет тебе банк сообщение о зачислении 10000 денег, ты же явно попросишь уточнить сумму! А что, вполне может сойти за нолик или за разделитель разрядов, да и десятичная точка из него тоже ничего так! Было у плательщика (бухгалтера, операциониста) хорошее настроение, решила смайликов наставить хорошему человеку.
хмл требуется обрабатывать быстро и так же быстро выявлять ошибки в нем.