graham.reeds <graham.reeds@g...> wrote in
<a07ebc34-67ed-4e7e-9109-f59b53294628@i...>:
> On Feb 1, 8:43 pm, Joseph Kesselman
> <keshlam-nos...@comcast.net> wrote:
>> graham.reedswrote:
>> > unsure about the second part - specifically the sending
>> > of data through the XSL file and having it append to
>> > the original file.
>>
>> XSLT is designed to always generate a new document. If
>> you're trying to update a document in place, you need to
>> write some code for the purpose.
> 
> It seems pointless to write what probably amounts to at
> least a couple hundred lines of Javascript when XSLT seems
> to be able to do what I want it to.

XSLT is a domain-specific language. You stuff an XML
document and a number of parameters into it, you get an XML
document out of it. As Martin said, if you want to
transform in-place, you have to write some code in a
general purpose language of your choice.

> @Pavel: Can you give a quick run through of your code for
> me?

No. Discussing the actual flow of XSLT processing with
anything but simplest transformations on smallest documents
is not really feasible in Usenet format. You could try
drawing the DOM trees on paper, and running the
transformation by hand. This tends to be a highly
enlightening exercise. Have the reference materials close
by. Don't stop until your results match those produced by
actual XSLT processors.

> I think I have the idea that the code runs from the 
> last section and the others handle what happens.
> data_?.xml gets passed in and chunk_?.xml
> get's passed out.

Um. Have you read any tutorials but the w3school's one yet?

> However the data.xml's don't provide a reference for the
> xsl stylesheet.

XSLT PI's are rarely used IME. You can run any
transformation on any document, no matter what the PI says,
and often you want to run more than one transformation on
the document, either sequentially or to get several outputs
in parallel.

XSLT PI's are only useful if their (limited) capabilities
are enough for your purposes, which doesn't seem to be the
case here. Typically, in web context, you invoke your
transformations using the XSLT API in you client- or
server-side scripting language.

Note that in web context you cannot rely on UA being
scriptable, on client-side scripting being enabled and on
XSLT engine being available, with API exposed to the
scripting language. This is only viable in closed
environments. In web context, transform server-side and
serve the results.

Server-side transformations are preferable in any case,
since you have full control over the transformation engine
you're using, and can easily switch engines mid-project
(assuming there is some sort of abstraction layer between
your code and the engine). TransforMiiX and MSXML engines
used by Gecko-baseds and IEs respectively are, generally
speaking, less capable than transformation engines
available elsewhere, such as libxslt, Xalan-J/C++ and,
especially, Saxon, which is on the very few XSLT2-compliant
processors.

-- 
<>There is no phenotype</>