xml порядок следования атрибутов в теге

а что по этому поводу говорит XSD?

Правильно ли поступили эти … ?

Глупый вопрос. Смотря кто сколько платит.

Вроде требование ничего не нарушает.

ЗЫ: радуйся. Мне один раз пришлось вставлять режим для выдачи пустых тегов

<test></test> Вместо <test/>

xsd нет, есть doc-файл, в котором описаны теги/атрибуты с комментариями структуры и вводимых данных.

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

я смотрю, намёков ты не понимаешь. нет такого механизма в XML, что было бы очевидно, если бы они попытались это описать в XSD схеме

Note that the order of attribute specifications in a start-tag or empty-element tag is not significant.

https://www.w3.org/TR/REC-xml/#sec-starttags

даже если бы и попытались, это было бы придурью шаражки, стандарт не гарантирует порядка следования атрибутов.

Правильно ли поступили эти … ?

требование, как требование. это вообще умолчательно при валидации xs:sequence каком-нить, да и вообще удобно при потоковом парсинге.

Есть ли такие проблемы при обработке на Perl?

Это у вас проблемы, а это требование. любой сериализатор в xml умеет order.

W3C – это не ISO, а их рекомендации – это не стандарт, если уж на то пошло.

сейчас бы путать теги с атрибутами

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

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

Их не спутаешь. Порядок тегов важен при описании списков.

При правильной аргументации можно не делать тупую работу.

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

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

и для чего же используется упоминаемый выше xs:sequence – для тегов или для атрибутов?

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

Это бред, я бы не делал. Не боись, скажи им, что у аттрибутов в xml нету порядка.

это хрестоматийная проблема написания кода склейки гетерогенных систем, его просто пошлют на хер.

Ну а он их пошлёт. Если им так нужен порядок, то пусть сами его и меняют.

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

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

Подозреваю, что в этой организации xml парсят, не как xml, а как текст. А тут, блин, атрибуты в произвольном порядке…

всё правильно сделали.

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

Не может, он человек подневольный, работу надо работать.

Всё он может, быть безмолвным послушным рабом не обязательно.

тут собственно такая же картина, нужно работать с тем что приходит.

Как я понял, он им отправляет xml. Это им приходится работать с тем, что приходит.

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

Всё он может, быть безмолвным послушным рабом не обязательно.

Держи в курсе, как говорится.

Как я понял, он им отправляет xml. Это им приходится работать с тем, что приходит.

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

Вот то-то и оно. Видимо у ТС не было до этого момента опыта работы в сфере интеграции систем.

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

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

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

Никто мне почему-то не говорит отсортировать ключи в json, например.

А потом придёт клиент с парсером вида (псевдокод)

reader.ReadNext();
a = reader.value;
reader.ReadNext();
b = reader.value;
reader.ReadNext();
c = reader.value;
reader.ReadNext();
d = reader.value;

и ты будешь сортировать, потому что гладиолус. Это печально, но бывает.

В слабых IoTинах, у которых тупо нет памяти на сохранение ответа сервера и стоит потоковый парсер, дёргающий по мере вычитывания JSON'a стейт машину, требования к порядку следования - обычная ситуация. ТС просто не привык к страданиям, это пройдёт.

Нет, я ему скажу, что его парсер надо переписать.

Ничего страшного, клиент найдёт более клиентоориентированного поставщика 👍

Разве это страдания? Вот когда требуется невалидный XML/JSON/whatever, это уже головная боль. Сам не сталкивался, но слышал.

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

Сталкивались с таким требованием в ЦБ, но технически это никак не было оправдано, просто при тестировании обратили внимание на то, что порядок атрибутов не соотвествует тому, что было в документации, а там очедедность указана была только для 3 атрибутов, для остальных не было сказано ничего. Пытались объяснить - не слушают. В итоге реализовали очередность для 3 атрибутов. А когда прошли интеграционное тестирование с другими системами, забили на очередность, ничего не сломалось - так и осталось.

Клиент сказал делать - значит, для чего-то нужно.

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

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

Согласен, если оно уже запущенно то это уже не остановить. Главное не допустить этого изначально.

По XML спеке, порядок атрибутов может быть произвольным.

Правильно ли поступили эти … ?

Порядок параметров в url после знака вопроса не желаете-с?

А какая разница? Вы их требования согласны выполнять? Если нет - пишите им, если да - зачем пишите здесь? Стандарты xml сами знаете где расписаны. Но, фиды со своими требованиями у каждого свои.

И что с того? Как это относится к вопросу ТС?

Есть ли такие проблемы при обработке на Perl?

Нет, конечно.

слегка по теме: https://dst.lbl.gov/~ksb/Scratch/XMLC14N.html

Ты пишешь на перле? Нам есть что с тобой обсудить. Я хочу его изучать, поможешь?

Владимир

Наша заказная система на Java формирует список атрибутов в алфавитном порядке.

В чем проблема расположить атрибуты в том порядке как требует заказчик?

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

https://stackoverflow.com/a/19269903

Порядок тегов важен при описании списков

Приведи пример.