[
Lists Home |
Date Index |
Thread Index
]
> > > I think it was Arpan Desai from Microsoft who talked about a
subset
> > > of XPath suitable for use in streaming applications at XML 2001.
If
> > > software had a priori knowledge of the xpaths, then it stands a
good
> > > chance of recognizing when streaming can be used and falling back
to
> > > tree mode only if necessary.
> >
> >1) Is this available anywhere?
>
> Apan's paper is at :
> http://www.idealliance.org/papers/xml2001/papers/html/05-01-01.html
>
> Sean
>
Regarding the potential use of a forward-only XPath in XSLT, the main
purpose would be to allow the processor to transform the document in
"chunks" rather than have to be loaded all at once. You could say that
there are two major ways that people use XSLT; one is to structurally
transform from one schema to another potentially quite different schema,
typically for EAI or B2B. The other is for content-oriented XML, where
the XSLT is being used to embellish and format the XML for printing in a
report or on a web page. Generally in the second scenario, the XML
structure is predictable and repetitive, and the transform itself is
fairly repetitive and recursive. For example, imagine a transform that
takes xml shaped like:
<author name="Tennison">
<book title="Practical XSL Transforms">
<edition binding="paperback" isbn="aaa-aaa-a" />
</book>
</author>
<author name="St. Laurent">
....
</author>
Now suppose that this catalog of books needs to be re-formatted a bit so
that the "edition" node gets merged up into the "book" node with the
"book" node having a new attribute called "isbn" that has nmtokens with
isbn of all the editions. This could be because a trading partner needs
the catalog in that format for importing to their database, because you
want to create a report showing one line per book, or whatever.
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 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? Obviously this is a simple scenario, and it is not possible
to know for certain in *all* cases whether or not a document can be
"chunked" using forward-only XPaths. But it is still possible and
worthwhile to analyze this sort of information in many cases.
Also note that the scenario I describe is not suggesting a replacement
or "upgrade" of XSLT. It is simply a potential optimization that can be
made in XSLT engines that are capable of understanding forward-only
XPaths.
smime.p7s
|
