Нет времени разбираться, что это такое.

Но в свое время делал генератор отчетов в Excel через его родной XML формат который он сам понимает (т.е. генерил отчет на основе шаблона который создавался в Excel по принципу - заполняй строчки данными с таким же форматированием как в шаблоне)
Так как использовался SAX парсер - скорость формирования действительно была огромная.

Как недостаток XML формат EXCEL не поддерживает вставку картинок, а в отчете это иногда нужно.
Ну и известное ограничение на кол-во записей на листе.

В общем кому что нужно

Ну то есть картинок у вас тоже нет.

XSLT вы используете здесь совершенно напрасно, для данного случая очень прожорливая технология по памяти и времени.

Рискну предположить, что возможен только один набор данных (датасет), нет ни вложенных отчетов, не отчетов на одном листе с разными detailами, отсутствуют передаваемые дополнительные параметры и вычисляемые во время работы отчета пользовательские выражения, нет page heder & page footer (т.е. тот что на каждой странице), нет page break (хотя это легко можно реализовать), наверняка косяк с подведением итогов в группах (я предполагаю что обычное суммирование все же есть), отсутствует возможность не печатать группы по условию и пр. и пр.
Извините (если с чем-нибудь не угадал, написано просто навскидку).

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

С уважением
Idid

>OLE работает горадо медленне, и требует клента на каждом компьютере. Для WEB непригодна.
>Формиовать "Родной" XML из программы бысрее, но убивает на корню идею визуального создания >отчётов. В моей программе внешний вид просто "рисуется" в Excel'е безо всякого программирования.

А мир у нас делится исключительно на OLE и XSLT.
Я не ставлю под сомнение ваш выбор генерации XML файла в формате Excel.
Только вот XSLT тут не причем. У этой технологии есть один очень жирный плюс -
это стандарт. И когда вы пишите программу в которой что-то может меняться др.
программистом не нужно выдумывать свой язык, проще использовать XSLT. Но когда
эта часть чисто внутренняя, ее никто не меняет и никто не видит - зачем там нужен XSLT?
Давайте разберем - вы из некого набора данных сначала генерируется XML - при этом расходывается памяти ну минимум в два раза больше, чем занимает набор данных, после чего этот поток грузится в парсер который реализует DOM (с другими XSLT не работает) - объем памяти необходимый парсеру в 3 раза больше чем XML файл занимает на диске. Плюс мы не можем сказать какие данные понадобятся отчету - т.е. грузим сразу все без разбора.
Мы потратили кучу времени и отъели в 6 раз (как минимум) больше памяти чем занимают первоначальные данные - вопрос зачем, потому что XSLT - это сейчас модно? Есть другой ответ - я знаю XSLT - почему бы мне сюда ее не впендюрить?

У нас главный критерий для программиста - А у меня это работает!!!
У вас же это работает - значит вы правы!

Количество требований к нормальной отчетной системе занимает как минимум несколько листов, я же предложил 8 - элементарных пунктов, у вас не реализовано 4 - так что я остаюсь при своем мнении (хотя о каком отчете вообще можно говорить без сумм - не понятно)

Вы наверное много сил и времени потратили чтобы написать то, что работает в данный момент. Я не хотел вас обидеть. Просто для того чтобы вашу систему могли использовать другие, нужно выйти на некий функциональный уровень (я даже не имею ввиду коммерческое распространение). Некоторые зарубежные авторы оценивают трудоемкость создания системы как 1/3 - для внутреннего использования и 2/3 - для распространения. Мне кажется, что вы и первую 1/3 еще не прошли. Извините, если мое мнение не совпадает с вашим.

С уважением
Idid