Какие технологические проблемы возникают при создании языка разметки для электронной почты?

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

"содержимое тега GOK должно быть целым числом, не превышающим общее количество тегов BREEP, содержащихся в предыдущем теге FLOIT"

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

Это не смертельно, но сложно, и не только это, это обманчиво сложно. Короче говоря, семантика, которую вам в конечном итоге потребуется внедрить в любом начинании, быстро потребует эквивалента логики первого порядка (если не второго порядка), что требует надежного языка описания. Такие языки существуют (сразу приходит на ум Common Logic, как и OWL Full) ... но тогда вам понадобится потрясающий механизм рассуждений, чтобы обеспечить соблюдение правил.

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