[
Lists Home |
Date Index |
Thread Index
]
I just realized that I have been replying directly to you and not
copying the list on all of these... Ooops!
> I am trying to stabilize my theoretical concepts. I am playing with
> XSLT in order to learn its features but I do not have to build any
> specific application right now.
Excellent. Its nice to see you tackling this subject head on :)
> >However, Oleg (and hes someone who knows a great deal in this area)
> >brings up a very good point and you really should consider his council
> >in this matter. It doesnt seem you are too worried about the
> >internals of the transformation process (or have I misunderstood?)
> >
> Actually, this is what I am interested in. I am sure that it will
> help me in the future if I understand how XSLT processors work (even if
> I cannot see the benefits right now)
It most certainly will. If I could suggest visiting Saxonica.com and
follow the links to the download of the Saxon-B 8.3 binary+source.
Saxon provides a complete implementation of the latest working drafts
of XSLT 2.0, XPath 2.0, and XQuery 1.0. Studying the source of Saxon
will go a long ways into understanding both the here and now of XML
transformation and query as well as what the future has in store in
regards to these three fundamental technologies.
>
> if you can save it some steps by using SAX throughout then
> >you're going to find some performance gains.
> >
> Everything is clear for me. I did not know that XSLT processor have
> their own internal representation of XML documents. That changes the
> landscape quite dramatically. It also makes sense because a lot of DOM
> functionality is not required by an XSLT processor (like changing the
> original XML instance)
Yeah, the "API" of both DOM and SAX are no longer relavent inside of
the actual transformation process... obviously the XSLT language
itself becomes the interface into manipulating the input tree into the
desired output tree at which point you can easily use SAX or DOM for
tweaking the in-memory representation of the transformed XML.
>
> >In every transformation process
> >exists...
> Steps:
>
> 1. tree building
> 2. stylesheet compilation
> 3. transformation
>
> I'll surely remember this.
As you work through the source of Saxon you will obviously learn TONS
more but this is a good place to start :) Saxon 8.3 also has support
for XOM (e.g. passing a XOM object to the process) so learning more
about this will surely help.
Best of luck to you!
On Sun, 27 Mar 2005 09:00:57 +0300, Razvan MIHAIU <mihaiu@mihaiu.name> wrote:
> M. David Peterson wrote:
>
> >
> >Sorry, I meant XSLT processor. And with Xerces I am assuming Xalan
> >but obviously it could just as easily be Saxon or a variety of
> >others...
> >
>
> Indeed, I am using Xalan.
>
> >More than the actual applications you plan to use I was meaning more
> >along the lines of what type of application you are planning to build.
> >
> I am trying to stabilize my theoretical concepts. I am playing with
> XSLT in order to learn its features but I do not have to build any
> specific application right now.
>
> >
> >However, Oleg (and hes someone who knows a great deal in this area)
> >brings up a very good point and you really should consider his council
> >in this matter. It doesnt seem you are too worried about the
> >internals of the transformation process (or have I misunderstood?)
> >
> Actually, this is what I am interested in. I am sure that it will
> help me in the future if I understand how XSLT processors work (even if
> I cannot see the benefits right now)
>
>
> > but
> >understanding what happens on the inside will aid your decision on
> >what format is best to pass the transformation engine. The chances
> >are mighty good that your XSLT processor will accept a DOM document
> >object but then optimize this to something more to its liking. As
> >such, if you can save it some steps by using SAX throughout then
> >you're going to find some performance gains.
> >
> Everything is clear for me. I did not know that XSLT processor have
> their own internal representation of XML documents. That changes the
> landscape quite dramatically. It also makes sense because a lot of DOM
> functionality is not required by an XSLT processor (like changing the
> original XML instance)
>
> >In every transformation process
> >exists a tree building process, a stylesheet compilation process, and
> >a transformation process. If the first two processes can use data
> >with an existing in-memory representation or a pre-compiled stylesheet
> >then all thats really left is performing the transformation and your
> >good to go.
> >
> Steps:
>
> 1. tree building
> 2. stylesheet compilation
> 3. transformation
>
> I'll surely remember this.
>
> Regards,
> Razvan
>
>
> >> I will look into it. If XOM is another in-memory representation of
> >>XML that is more memory - efficient than DOM then this could be very
> >>interesting.
> >
> >
> >I think you might find a nice middle ground in XOM.
> >
> >Cheers :)
> >
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>
--
<M:D/>
:: M. David Peterson ::
XML & XML Transformations, C#, .NET, and Functional Languages Specialist
|
