Re: Beginners question: Koala XSL-Engine and <xsl:process se

One case in which I would want the root node to be distinct from the document element would
be if multiple XML documents are sharing the same DTD (and being processed by the same XSL
file) but have different document element types. For example, these two documents might share
a common DTD:

- - - - -
<!DOCTYPE book SYSTEM "my-writing.dtd">

<book>
    <chapter>
        <section>
        </section>
    </chapter>
</book>
- - - - -
<!DOCTYPE chapter SYSTEM "my-writing.dtd">

<chapter>
    <section>
    </section>
</chapter>
- - - - -

If I want an XSL script to transform these files into HTML, I need to apply formatting to
<chapter> and <book> elements, but I also need to wrap the whole thing in the standard HTML
boilerplate.

If the document element is referred to as "/", then my "/" rule needs to generate the HTML
boilerplate, then test the current node's tag (which is not supported yet), and do either
"book" or "chapter" processing.

But if the "/" node is distinct from the document element, as in the current XSL WD, I can
easily write one XSL script for all possible documents based on my DTD. The "/" rule will
simply generate the HTML boilerplate and call <xsl:process-children/>, and separate "book"
and "chapter" rules will handle their respective element types, without having any hardcoded
knowledge that they are or are not at the top.

- Steve Dahl
sdahl@xxxxxxxxxxx


Tyler Baker wrote:

> Paul Prescod wrote:
>
> > Tyler Baker wrote:
> > >
> > > That is one way of doing things I suppose, but I don't like this at all as it is
> > > confusing to deal with.  It still seems silly to have to refer to the root node when
> > > only one element of a particular type can be the document element.  Referring to the
> > > document element like any other node makes working with the DOM a bit of a kludge
> > > since you have to essentially create a dummy node that lives on top of the document
> > > element.
> >
> > It isn't a dummy element. It is the logical holder for document-global
> > information: examples include the DTD, the list of entities, the list of
> > IDed elements, etc. It turns out that XSL is not powerful enough to use
> > any of that information but that doesn't mean that the idea of a "document
> > node" separate from an "element node" is a bad one.
>
> Well it is just that it is called a root node to begin with.  If it was called the
> document node, then this confusion would not be an issue, but all of this information is
> metadata nevertheless and not content.  With respect to processing, the content of the
> document is contained only in the document element and all subsequent elements so I still
> see no reason why the root node should not be defined as the document element itself as I
> would think most newbies to XSL in the future will be able to understand the idea of the
> root node being bound to the document element, than some invisible element that is
> actually not an element at all (has no attributes, or content, just a single child node).
>
> Tyler




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