Re: stylesheet organisation

>> > XSLT is not all that good at being used in large, multi-programmer
>> > projects;
>>
>> That's just not true, there's nothing different or special about xslt
>> than any other language used in a large project.
>
> Many other languages have more support for the idea. (Since there are
> (apparently) very few really big, 10+ programmer, XSLT projects, this is
> not surprising.)
>
> XSLT, for instance, doesn't have an equivalent of header files, or a
> notion of "partial build".

Not sure what you mean there... you can have multiple entry points
(say root matching templates) so you can run a subset of the transform
that all ultimately get overridden by the main entry point.


>> > there's little-to-no automerge support for version control,
>> Again not true... what makes you say that?
>
> The gibbering horrors you get when a version control system with really
> very good line-based code merge algorithms tries to do line-based merge
> on XSLT, where you really do want a node-based merge.

Ok, I've never had a problem with it.


> And this works, but every single (you understand that this is a much
> simplified example; the real case gives me many warnings) such import
> produces a "imported or included more than once" warning.  Which both
> hides things I would care about in the warning list, and makes the "was
> there anything in the log file?" check for "that transform worked" less
> useful in a batch-processing context.
>
> So I suspect that there's a better way to do this.  What that way might
> be I have yet to discover, though.

Which XSLT processor do you use?  I'm not sure it should be giving you
those warnings, see:

http://www.w3.org/TR/xslt20/#element-import

"The case where a stylesheet module with a particular URI is imported
several times is not treated specially. The effect is exactly the same
as if several stylesheet modules with different URIs but identical
content were imported. This might or might not cause an error,
depending on the content of the stylesheet module."




--
Andrew Welch
http://andrewjwelch.com