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

RE: Co-operating with Architectural Forms

• To: "'Joshua Allen'" <joshuaa@m...>,"'Sean McGrath'" <sean.mcgrath@p...>,<xml-dev@l...>
• Subject: RE: Co-operating with Architectural Forms
• From: "Michael Kay" <michael.h.kay@n...>
• Date: Sat, 2 Feb 2002 14:45:22 -0000
• Importance: Normal
• In-reply-to: <4F4182C71C1FDD4BA0937A7EB7B8B4C1041814BD@r...>
• Reply-to: <michael.h.kay@n...>

> The common problem that arises here is that someone has a 500MB XML
> catalog and their machine bombs when they try to transform the whole
> thing at once.  So they write a SAX reader that grabs each "author"
> element and transforms it individually using a cached XSLT stylesheet.

This is in effect what Saxon's saxon:preview extension does for you.

> This happens unfortunately very often.  So the natural 
> question becomes,
> if the XSLT stylesheet has a base template that calls
> <xsl:apply-templates match="author" /> then why doesn't the
> transformation engine just figure it out and do the right thing under
> the covers?

I think the number of cases where you can do this automatically is rather
limited, though it might become rather more feasible if the optimizer has
knowledge of the schema. It only takes a single template that uses "..", or
a leading "//", or <xsl:number/>, or key(), or various other things, to make
the optimization invalid, unless you know for certain that these are only
selecting within the current subtree.

Mike Kay

<<attachment: winmail.dat>>

• References:
  • RE: Co-operating with Architectural Forms
    • From: "Joshua Allen" <joshuaa@m...>

• Prev by Date: Re: XPointer crisis
• Next by Date: Re: RELAX NG
• Previous by thread: RE: Co-operating with Architectural Forms
• Next by thread: RE: Co-operating with Architectural Forms
• Index(es):
  • Date
  • Thread