Re: [xsl] Still not getting document() function

Subject: Re: [xsl] Still not getting document() function
From: "Jon Gorman" <jonathan.gorman@xxxxxxxxx>
Date: Thu, 13 Apr 2006 15:44:01 -0500
> Thanks for the example.
> > Modify these as appropriate.  You'll probably want to make
> > addReport change the text and not docname.
> What is addReport?

Meant the addReportTo element.  In my examle I changed it so whenever
a lab:docname matched it had different text.  (If you try running it
against the sample you gave you'll see what I mean).  You'd presumably
want to add "Additional Report To:".  If you can follow my example and
try playing with it it should be pretty easy change.

> Okay, bigger picture.  We send data to a company, where they analyse it and
> return a set of files.  We get a PCL, PDF and XML file back from them.
> we want to do next is generate the mailing address on the front page.  Now,
> we don't send the client information because it is confidential (otherwise,
> the other company would be doing this).  Also, we could send this out to
> more than one client, depending on how the client is set up, as some
> have "master" clients as well.  This is why I need to generate client info
> on the fly.  Another reason to do this is we can store one copy of a report
> (with no client info) for internal display, but we can then create a report
> as a .pcl file to send to a client as a fax.  Finally, we'll always be
> sending from the most up-to-date client information.

Good reasons.

> > > 1) Create the XML file with all addresses, then modify the XSLT file
> > > to do a for-each;
> > > 2) Create the XML file with one address, transform, create another XML
> > > file, transform.
> >
> > This seems like a red herring.  What does this have to do with the
> > document() questions?
> It's a matter of how to set up the logic; it could be easier one way or
> another, but I'm not sure which, and some of you XSL experts might know
> which is better.

The factors that would affect this have little to do with the
document().  Processor, environment, optimization, and workflow all
have impacts.

Decide how you want to output the documents since it'll have much more
of an affect on the  process.  It would be mostly dependent on the xml
that you're processing, not the "additional" information brought in by
a document call.

There more than one way to do it.

> > > Basic question #2: is there any improvement I can make to
> > > the output file so that it's easier to select the data?  The
> > > only thing I want to keep are the names of the data nodes
> > > (docname, addrName, addrStreet, addrZIP, addrZIP2, addReportTo)
> > > because these are object names.
> >
> > How the heck are we supposed to know the answer to this when
> > we don't know why you're selecting certain elements?
> Hopefully, the bigger picture I presented above answered that.

Not really.  I mean, we only have a vague idea of the data..
Pointers: use id attributes.  Make sure they're unique across all
documents and not just the individual ones.

I mean, you could keep everything in one place, then transform the
info that you hand to the clients so the information never needs to be
seperate.  Using extensions or a XSLT 2.0 document you could use
result-doc to create many different documents.  You could have a
script that calls the xslt proc multiple times and passes in

Jon Gorman

Current Thread