> Well, if you need the exact same code, this is a pretty good indication > that it probably shouldn't be in the XSLT translator at all... Working > on top of a directory tree would only make sense if it would actually > use the provided structure directly, rather than first serializing it. > > Or do you mean just the part that reads the directory structure and > constructs an internal DOM tree from it?
Yes, that part. > I don't think the XSLT translator should present a directory tree as > output. Nothing in XSLT requires the output to be XML. Aha, I had a feeling I was misunderstanding something somewhere. In that case, xslt would be even simpler - the code would be pretty much the same as unxmlfs (turn an xmlfs directory tree into an internal DOM representation and present it as output via trivfs), but just with a transformation performed. In fact, if that's the case maybe even just a "--xslt=FILE" option to unxmlfs would do the trick. However, XSLT is commonly used to turn one XML document into another, so perhaps there should be an option to try and present it as a directory tree, but default to presenting just a single file. I need to think about that. In any case, that's not adding much complexity (probably simplifying things in some areas, in fact). -- Michael Walker (http://www.barrucadu.co.uk) Arch Hurd Developer; GNU Webmaster; FSF member #8385 http://www.archhurd.org http://www.gnu.org http://www.fsf.org
