Re: [xsl] many to one OR one to many?

[Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>]

Jason:

First, this is only sort of on topic. You'd have the same question if you 
weren't using XSL. :-)

Second [off topic] ... the answer depends. In general the one-to-many 
solution will be easier to engineer (think about managing cross-references, 
for example). But there are file and content management issues (i.e. not 
XSLT engineering at all) that might overbalance this convenience, such as 
the total quantity of data (how big would that file actually be?), how (and 
by whom) it is edited and managed, etc. etc. And strategic questions: maybe 
your data will fit nicely into a single file now, but what if it grows? 
(Might it? How fast?)

Also, keep in mind you don't have to do your production in one step. (You 
probably won't in any case.) You could maintain your data in separate 
files, then glom together (convenient for certain kinds of editorial work), 
then split apart. A one-to-one correspondence from XML source to your HTML 
output may be very nice to have (the lmnl.org web site is built like this) 
particularly if your overall design is very "webby"; but it's not the only 
way to do it even if you go with multiple source documents.

The core problem you should be thinking about is designing and maintaining 
your entire workflow, not just your production process. Depending on your 
organization as well as the quantity and design requirements of your data, 
going from one big file could be perfect, or a disaster.

Your question about tools really falls into the same category. Given how 
contingent they are on the particulars, questions like yours are what keep 
consultants in business. :->

Sorry not to be more help. It's a complex issue. Hopefully others will also 
have something to say.

Cheers,
Wendell

At 11:31 AM 4/1/2003, you wrote:
> I'm looking at converting some training materials we have (in Word 
> currently) to XML/XSLT.  The target is Web/Web-printer-friendly/print 
> output.  Server resources are a sensitive issue and updates aren't going 
> to be daily or even weekly, so the web version will be batched to static 
> files with some dynamic functionality (search, most-accessed-topics etc.) 
> wrapped around it via keywords and some PHP. So...the output for the web 
> is multiple files, while the print is [ideally] one document (PDF). The 
> material will mainly be organized as 'reference'.
>
> I'm wrestling with:
> whether I would go with multiple small xml files that I could compile into 
> one output for the print, but would match the html files essentially
> OR
> one xml source file that matches the print, but can be output into 
> multiple files (via some element in the structure that separates) for the web.
>
> I would prefer the multiple xml to one for editing management and because 
> IMO, the web output is more important...especially since there will be a 
> web printer-friendly version.
>
> Anybody experienced one or both of these scenarios and have some 
> pointers?  I have seen some references to doing this, but not much more 
> than that.
>
> Also, I am investigating user-friendly XML/XSL tools for the rest of the 
> group. XMetaL by Corel is the lead candidate at the moment. Any other 
> suggestions?
>
> TIA!
>
> Jason
>
>
> XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


======================================================================
Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
----------------------------------------------------------------------
  Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================


XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list