Вопросик намечается. В том смысле, что сам пока такого не делал и примеры не встречались.
Простая трансформация - XML+XSLT=>выход - уже давно всеми освоена и проблем не вызывает.
Т.е. пока Я работаю со своим собственным форматом все прекрасно. Однако есть желание
переползти на что-то, что более-мение стандартизовано. Например - на XSD. Поковырялся в
генерируемом Студией XSD - там наворочено namespace'ов без нужды. Написать на C# разбор
и генерацию упрощенного XML - проблем нет, но интерес представляет - написать прямую
XSLT-трансформацию - XSD+XSLT=>выход.
Вот сижу и ищу примеры обработки namespace'ов в XSLT. Кто такое видел - киньте ссылку.

А что сложного ? Все название элементов аттрибутов предварять именем прострастранства.

Хммм... просто в лоб писать квалификатор в выборке и все?
Я надеялся, что может чего более интересное сделали - например, оформления описания правил трансформации так, чтобы они были применимы только в определенном контексте и не возится с квалификаторами внутри...

Все что не относится к default namespace должно быть исключительно названо..
вот такой кусочек xslt (xml->html)
<xsl:for-each select="ti:TestTelegramTemplates/ti:TelegramValue">
<p>
<a href="?sendtelegram={@Name}">
Send telegram <xsl:value-of select="@Name"/>(<xsl:value-of select="@TelegramType"/>)...
</a>
</p>
</xsl:for-each>

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

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

У меня примерно следующая схема:
XML(1) -> сборка (синтез) "подходящего" XSLT(2) -> трансформация XML(1)/XSLT(2) -> (sql скрипты, код бизнес-объектов, код форм).
Ищу способ упростить фазу сборки(синтеза) XSLT для еще не определенного XML.

И хотите синтезировать "подходящий" XSLT на основе схемы описывающей ваш 1-й XML, так?

Примерно так.
Схемы, по идее, должно хватать, но пока не нашел как это все сделать, если сняты все ограничения на исходный документ. Да и в жизни все сложнее - там неограниченное количество входных XMLов разных форматов.

Я, честно говоря, не думаю что такое в принципе может работать если сняты все ограничения на входящую схему... Ну дам я на вход схему, описывающую элемент Ж у которого два обязательныч атрибута О и П и один опционалный ребенок А :) И какой алгоритм будет угадывать что я этим Ж имел в виду?
Как минимум ограничение на имена элементов и атрибутов должны быть, или я что-то не понял?

или я что-то не понял?
-----
Где-то в глубинах базы есть 2-3 тыс различных определений для Ж для разных ситуаций. Выбирается наиболее подходяцая - т.е. та, которая предполагает использование О и П и (опционального) потомка А для получения заданного результата. Требуемый тип результата может быть частью исходного XML документа или получаться как требуемая часть промежуточного результата.
Отсутствие прямого преобразования - не проблема. Бо, есть возможность найти обходной путь или потребовать доопределить использование Ж в определенной проблемной ситуации - система как раз накапливает подобные решения для будущих применений, но это другая часть...
И какой алгоритм будет угадывать что я этим Ж имел в виду?
------
Никто не будет. Скажем, что предполагается, что необходимо построить скрипт для создания таблицы - генерируется один XSLT, потом - требуется построить скрипт для апдейта таблицы - строится другой XSLT, но в нем, по возможности, используются те же части, что и в первом. Разумеется - не 100% тоже самое, но весьма многое используется повторно. Что именно строить - определяет исходное требование для выходного документа, а задача - собрать нужный XSLT для его получения.