Эдуард Тибет

У вас изначально неправильно поставлена цепочка преобразований.

В правильном варианте то, что вы перечислили, является представлением исходного контента в xml, Т.е. конечной точкой. А не наоборот.

Я вам больше скажу по этой теме.

Есть ГОСТ Р ИСО/МЭК 26300-2010 ( Информационная технология. Формат Open Document для офисных приложений (OpenDocument) v1.0)
А есть еще ГОСТ на PDF (тоже тянутый с ISO) - не помню номер, можете погуглить.

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

Есть даже статья на хабре по этому поводу - https://habrahabr.ru/post/181900/ (м.б. и другие есть статьи)

1. Если надо именно _полиграфическое качество_ (т.е. ориентированное на типографию: с цветоделением, crop marks и т.п. штуковинами), то решение - кастомный xml и возможности InDesign по использованию xml-содержимого.

Есть даже специальная литература по этому поводу: "XML Publishing with Adobe InDesign " (shop.oreilly.com/product/0636920015949.do)

2. Если же НЕ надо полиграфическое качество (в просто обычный качественный pdf), то решение: кастомный xml (под данные вашего отчета) >> xsl:fo >> fo >> pdf . Т.о. вы будете получать гарантированное содержимое (дизайн) с изменяемой частью (данные). Можно даже это все дело запихать в CI :)

На вскидку: xml (c вашей схемой, будь то DTD или W3C Schema или RelaxNG) >> xsltproc (libxslt) | saxon | xalan [для шага xml > fo] >> FOP [для шага fo > pdf]
И все - с нулевыми затратами по софту.

П. 2 применяется в документации и называется "Технология единого источника в технической документации" (Single sourcing technical documentation).

xsd > кастомный xsl > DocBook xml source > Docbook xsl "out of box" > txt, man, html, html chunked, chm, pdf из одного исходника - что пожелаете :)

Но все-таки надо заметить, что xsd - это все таки именно схема (хоть с xml-based) с правилами. Вы уверены, что хотите экспортить именно xsd, а не xml, использующий эту схему?

1. Насколько большое ПО по функционалу сейчас и предполагается?
2. Какой тип информации вы хотите размещать там? Высокоуровневые требования, технические требования, архитектуру, пользовательскую документацию или все вместе?

А почему вы не хотели изначально использовать rsync???

Если не надо ограничивать траффик и другие squid-подобные вещи, то самое легкое решение: dnsmasq. Эта штука может работать с режиме masquerading.

Клиентов - юр. лиц или физ. лиц?

Вы не забыли про 152-ФЗ ?

Вам надо:
1. Посмотреть здесь: schemaspy.sourceforge.net
2. Потом посмотреть здесь: dba.stackexchange.com/questions/515/how-do-you-doc...

Если целевой документ не будет требовать редактирования ПОСЛЕ внесения информации о контрагенте, то оптимальной в вашем случае представляется схема:
xml (c variable-данными) + xsl:fo (шаблон) > pdf (результирующий документ). В этом случае вы гарантированно получите результат, при котором документы будут отличаться только на величину содержимого xml-файла с данными.

Посмотрите вот здесь: Где сисадмину хранить документацию и конфиги серверов, а также собственные наблюдения и размышления?

Там приведены аргументы ПРОТИВ использования любых вики-систем для документирования сетевых ресурсов.

Сначала определитесь, какой формат вам необходим. Это можно сделать по _полным_ требованиям к документации и сравнением "требования <> возможности формата".

В общем случае под ваши требования:

Т.е. должна быть функция фильтрации описания, в зависимости от версии и релиза, или возможность раздельной публикации.

подпадает любой src-based формат (неважно, plain text или xml-based), который можно хранить в ветках в дереве SCM.

Вы поясните - каких процессов? Процессов разработки софта или процессов приема/увольнения работников?

Далее... Непонятно с чего вдруг "Теперь все дружно решили попробовать "как надо"."
Есть какие-либо проблемы при существующих подходах? Если да, то какие.

Вопросы подобного плана обычно задают по схема: "Есть условие А, есть проблема Б, как ее решить при ограничениях В?".

Для таких вещей существует rsync

Странно, вы говорите про "не хочется проблем из-за миграции", но забываете, что Google Docs может ввести плату на раз. Например, при превышении определенного количества документов и т.п.

Раз уж вы настолько думаете о проблемах миграции, то ваше дело - хранить в одном из ФОРМАТОВ (лучше стандартов) в SCM, а не размениваться на GD.

UPDATE: Кстати, вот и подтверждение моих слов о гугле. Прямо в соседнем топике:
"Все было хорошо, пока его не закрыли - начал искать у гугла альтернативу и зашел в тупик." Подробнее... Где именно граница в Google Custorm Search API между «Paid» и «Free», 2016?

добавлю к предыдущему комментарию

"... и никакого ворда" :)