[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: "Joshua Allen" <joshuaa@m...>
• Date: Sat, 2 Feb 2002 00:52:59 -0800
• Thread-index: AcGrG41/beRI9cpuT/60zkHraCXliAAp3B6AAADdo9A=
• Thread-topic: Co-operating with Architectural Forms

Oops!  Just seconds after I sent this, I realized that "Practical XSLT
Transforms" is "Holman" and the "Tennison" book is "XSLT and XPath on
the Edge".  (And of course there are too many "St. Laurent" ones besides
"XML Elements of Style" to name them all :-)).



> -----Original Message-----
> From: Joshua Allen [mailto:joshuaa@m...]
> Sent: Saturday, February 02, 2002 12:47 AM
> To: Sean McGrath; xml-dev@l...
> Subject: RE:  Co-operating with Architectural Forms
> 
> > > > 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

• Prev by Date: RE: Co-operating with Architectural Forms
• Next by Date: Re: What am I overlooking...?
• Previous by thread: RE: Co-operating with Architectural Forms
• Next by thread: RE: Co-operating with Architectural Forms
• Index(es):
  • Date
  • Thread