Re: [xslt] Re: [xml] Iterating through multiple HTML docs

["Christopher R. Maden" <crism maden org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At 00:46 1/4/02, Daniel Veillard wrote:
>   Hum, actually, no, they aren't there anymore. What happens is that
>libxslt create a new document, in that extension function, process the
>related XSLT instructions, and once done, serialize the document and
>free up the result tree. At the end of the stylesheet processing the
>result tree returned is only for the main instance.

Ah - I see!  I hadn't realized that, but commenting out the serialization 
call shows that the subsidiary files are created anyway.

It looks like instead of <xsl:document>, I should use <my:document> and an 
XML output type, do the post-processing, and then call another conversion 
to HTML with the identity transform, except changing <my:document> to 
<xsl:document>.

>   That's the problem with extension functions in general, they were not
>part of the standard and it takes time to really grasp all the aspects
>required to integrate them properly :-\

)-:  My suggestions would be:

1) Keep the <xsl:document> node in the output tree in whatever context it 
occurred, and serialize it at the same time as everything else.  (This 
could get messy if it appears, for example, in the middle of a PI.)

2) Allow XML_DOCUMENT_NODE etc. to be children of other nodes, and turn 
xsl:document into these.  The nodes would need to have URIs associated with 
them.

3) Create separate document objects in memory, but put a node (PI or 
something special) in the parent document with some kind of reference 
that's traversable.

All of these suggestions would also resolve the problem that libxslt 
currently handles relative URIs relative to the CWD instead of to the 
parent document; that behavior makes a lot of sense if the children are 
serialized first, but deferring serialization would make the intuitive 
behavior much easier to implement, I'd imagine.

What do you think?

~Chris
- -- 
Christopher R. Maden, Principal Consultant, crism consulting
DTDs/schemas - conversion - ebooks - publishing - Web - B2B - training
<URL: http://crism.maden.org/consulting/ >
PGP Fingerprint: BBA6 4085 DED0 E176 D6D4  5DFC AC52 F825 AFEC 58DA
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.8

iQA/AwUBPKglZqxS+CWv7FjaEQIplgCg0SLqz6rccUem6byCsQsHink75bgAnib1
v9n9dDnms0fAHbpd/iHr9jPY
=tCC2
-----END PGP SIGNATURE-----