[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Didier's lab report

• From: Didier PH Martin <martind@n...>
• To: Xml-Dev <xml-dev@x...>
• Date: Wed, 26 Jul 2000 09:30:35 -0400

Hi

After a couple days on my bicycle, camping under the stars, some fresh air
and a lot of oxygen to the brain :-) I got back to the lab with new
experiments in mind.

During the last weeks, I got this question in my mind: "what is the
difference between the xinclude and the <xsl:apply-template
select="document(...uri)/path"/> construct? I mean, concretely speaking, can
I obtain the same result - aggregate content - with both constructs? is one
better than the other or simply an other way to do the same thing without
any major differences?

I got the insight while cycling on a flat road, during a quiet day and no
traffic...

The document function:
----------------------
XSLT allows the aggregation of content with the document function. You can
insert several document fragments into a main document. The
xsl:apply-templates gives you the freedom to insert the syndicated content
almost anywhere in the target document. It also allows you to extract a
nodelist from this document. This nodelist can then further be matched
against templates. So far, so good, we can aggregate external content with
XSLT. Now, the next question is: how fast?

All the XSLT processors I tested where requesting the external content only
when the interpreter encountered the document function (located in the
select attribute). Thus, these processors are basically doing a sequential
processing. The implications on the performance are not to be taken so
lightly. Let's imagine that you want to create a portal using XSLT as an
aggregation tool. Let's further imagine that the final document has to be
the result of the aggregation of 10 documents in addition to the main one.
Hence, we'll have a main document which aggregates ten external documents.
If we use an XSLT engine to do the processing (an XSLT engine actually on
the market), this latter will sequentially process the document and thus
will request the external documents only when the xsl:apply-templates
construct is encountered. So, the access time for each external document
access is to be added. If the average access time is 5 seconds, then the
overall processing time will be the  (time to process the document with
XSLT) + ( (5 second) X (10 documents) ) = XSLT processing time + 50s. This
means that if the XSLT processing time is 1 second then the overall
processing time is 1s + 50s = 51 seconds. Thus, the overall processing time
is 51 seconds. OK, now let's compare this to an xinclude processor.

the xinclude construct:
----------------------
The xinclude processor can recognize an xinclude enabled element when this
element contains an xinclude attribute (according to the last WD it is a
kind of architectural inheritance). So, to take the same example as
previously, the xinclude will recognize 10 external documents to be included
in the main document. It is even possible to tell the xinclude engine to get
only a portion of the external documents with Xpointer construct as values
for the xinclude:href attributes. The Xpointer constructs can point to a
document fragment but won't, as it is the case for the XSLT processor,
returns a nodelist. It will include only a fragment (i.e. an
element+element's content). Now, what about the time? The xinclude can
easily do some parallel processing in the target document since the xinclude
constructs are located in different places in the infoset. Thus, all the
inclusion operation can be perfomed in parallel. Thus, if the average access
time for all the documents is 5 seconds and if the documents are retrieved
in parallel (mostly at the same time), then the overall access time for all
the documents is 5 seconds. Hence, the overall processing time if we then
apply XSLT processing on the result is:
XSLT processing time + 5s. Hence 1s + 5s = 6 seconds.

Conclusion:
-----------
We have now simply to compare the aggregation operation time:
XSLT processing time + 50s for using the document function. (51 seconds)
XSLT processing time + 5s for using the xinclude and the XSLT processing
without the document function. (6 seconds)

In the case of aggregating external content, the "time consumer" is
obviously the network access and the network latency. Any measure to reduce
the access time will reduce the overall processing time since the local
processing time is about the same.

Thus the result is obvious , the winner is xinclude from the performance
standpoint as long as the xinclude processor is using parallel processing.
The question is now: Can an XSLT processor use parallel processing for the
<xsl:apply-templates select="document()"/> construct?

I let this question open to the XML community but at least now, you know why
the xinclude element may be necessary. At least from the pragmatic point of
view for those having to do real life stuff.

cheers
Didier PH Martin
----------------------------------------------
Email: martind@n...
Conferences: xmldevconf2000 (http://www.xmldevconf2000.com)
Book: XML Professional (http://www.wrox.com)
column: Style Matters (http://www.xml.com)
Products: http://www.netfolder.com

Didier PH Martin
----------------------------------------------
Email: martind@n...
Conferences: Web Chicago(http://www.mfweb.com)
             XML Europe (http://www.gca.org)
Book: XML Professional (http://www.wrox.com)
column: Style Matters (http://www.xml.com)
Products: http://www.netfolder.com

• Prev by Date: DTD conventions/best practice - using an parameter entity referen ceto specify element content, rather than doing it directly.
• Next by Date: Re: Question About Namespaces and DTDs
• Previous by thread: RE: Didier's lab report
• Next by thread: RE: Didier's lab report
• Index(es):
  • Date
  • Thread