Nano Hash - криптовалюты, майнинг, программирование

Работа с быстро меняющимися XSD в гибкой разработке

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

Что еще хуже, нашей целью является база данных, макеты таблиц которой также должны соответствовать быстрым изменениям. Я решил часть базы данных, но у меня нет идеального решения для достаточно быстрой обработки различий XML/XSD.

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

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

Я использую имена файлов xsd, такие как YYYY-MM-DD-SEQ.XSD, например

Должен быть более простой способ сделать это, но я не нахожу способ. Я действительно не хочу тратить время на программирование генератора XSD, но, возможно, это лучший способ? Есть ли лучший, более простой способ?

29.07.2015


Ответы:


1

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

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

Я разработал систему, в которой каждый XML-файл, который мы обрабатываем, проверяется в одном из нескольких версионных XSD-файлов (начиная с самой последней версии и заканчивая самой старой).

Отказ от правильной роли схемы — вот что неправильно.

Должен быть более простой способ сделать это, но я не нахожу способ. Я действительно не хочу тратить время на программирование генератора XSD, но, возможно, это лучший способ? Есть ли лучший, более простой способ?

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

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

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

Если внешняя группа не может идти в ногу, то у вас есть проблема более высокого уровня, которую следует решать напрямую, а не заметать под ковер. Либо они ускоряются, либо вы замедляетесь, либо вы принимаете несоответствие импеданса и разрабатываете этап явного преобразования, чтобы разделить две системы и сократить разрыв. Версии XSD будут быть вашим проводником в разрыв. XSLT очень хорош для преобразования XML между двумя версиями XSD; его можно даже использовать для предоставления фиктивных данных, которые другая система еще не генерирует в действительности. Если вы не можете сопоставить свои скорости изменений между двумя группами, вы, по крайней мере, сможете явно контролировать, какие изменения могут быть поглощены какой из групп в их временных рамках.

[1] Что-то не так, если реальная основная проблема заключается в том, что еще слишком рано фиксировать определение интерфейса.

29.07.2015
Новые материалы

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

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

Частный метод Python: улучшение инкапсуляции и безопасности
Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..

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

Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..

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

Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..