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

[Daniel Veillard <veillard redhat com>]

On Mon, Apr 01, 2002 at 01:16:22AM -0800, Christopher R. Maden wrote:
> 
> -----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 

  That could be one way, define a specific new extension. But your
requirement sounds generic enough that it should prossible to handle
it natively.

> 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>.

  Hum, yes if you want to see a single tree, that's a possibility.

> >   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.)

  Hum, yes that's messy because libxml has no such concept of a document
within a document, and that would require serious internal changes to
specify that kind of new nodes and handle them appropriately. Basically
this doesn't match the XPath data model nor the Infoset one, so it gets
really messy.

> 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.

  DOCUMENT nodes have URI associated to them. But again having document node
children of other nodes is a huge change.

> 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.

  I don't see an easy way to do this and expose an API for it.

In all 3 cases you're asking for an extension of the XML document model,
in the case 3) than could possibly be implemented as a simple layer on
top of the existing one as custom client code, but 1) or 2) are really
huge changes.

> 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?

  I think you have a problem which requires the post processing, 
which is apparently related to URI base but I don't understand exactly
why and how. The suggested changes are heavy and not in line with the
existing XML data model, so I'm getting really confused. Could you
explain what your problem really is with <xsl:document> ?
  If your problem really is that you don't know at XSLT processing time
what the final URI target for those xsl:document is then I'm afraid it is
a limitation of xsl:document. If the problem is related to the  URI target
for those xsl:document and that can be computed at XSLT processing time,
then what is missing for doing that computation ?

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/