RE: [xsl] Advice/feedback on stylesheet?

Subject: RE: [xsl] Advice/feedback on stylesheet?
From: "M. David Peterson" <m.david@xxxxxxxxxx>
Date: Tue, 30 Mar 2004 13:08:11 -0700
Sorry for the late reply to this Jim...  The weekend became a bit more
hectic than originally planned and I retired quite early last night to
catch up on some much needed sleep.

> building a temporary tree and of using the mode... Are there any
concerns/drawbacks of taking this type of approach when working with
large sets of data? (ie, would memory/resource use possibly be a
problem?)

I don't know of any specifically other than the obvious fact that the
larger your XSLT tree is the more memory it will consume.  Beyond the
obvious(im sure you are referring more to particular methods of
transforming data taking more resources than other methods) unless the
possibility exists that there could potentially be hundreds of different
mode matches to the same element name I don't see it becoming much of a
resource issue.  However the better person to answer a resource related
question would probably be Michael Kay or any one the other guys on this
list who are intimately familiar with the inner workings of XSLT
processors and the effects caused by different methods of transforming
data. 

> So, any further info/advice that you can provide in the context of
this generic/service approach to the problem would be most welcome!

Let me take a look at the original source file for this and see but it
seems pretty cut and dry.  Each node (whatever the name) will always be
a child element of "rowset" or whatever other name oracle decides to
call the containing parent element.  So, by using "child::*" in the
match attribute of the first template and then "child::*" in the select
attribute of the first apply-templates (within this first template) will
give you a subset of the children who parent is a child of root.  Then
just using "*" as your match attribute along with the correct mode you
would get the same result as if you had used that actual name of the
element.  Keep in mind that this is assuming that all the grandchildren
of root have the same name or, if they don't, the same rules for
processing apply to them.  

Ill look at this a little later this afternoon and see if I can prove to
make the same stylesheet work with the same data without using any
specific element names.

Chat with you later...

<M:D/>



-----Original Message-----
From: Jim Stoll [mailto:jestoll@xxxxxxxxxx] 
Sent: Monday, March 29, 2004 2:14 PM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: RE: [xsl] Advice/feedback on stylesheet?

Hi M. David,
Thanks for your reply and example - I look forward to seeing your site!
(and I'm glad that I could provide some input to your site, even if in a
wholly passive manner... :-)

I definitely learned some things from your response (and am still
contemplating a few of them) - I especially like the possibilites
associated with building a temporary tree and of using the mode
attribute of the select and match conditions - that's a new technique to
me and looks to have a lot of very cool uses!  Are there any
concerns/drawbacks of taking this type of approach when working with
large sets of data? (ie, would memory/resource use possibly be a
problem?)

As regards the original problem itself, what I'm trying to do is to
provide a generic stylesheet that users can apply to any set of data
resulting from a particular type of database query - I'm using Oracle
9.1, which allows hierarchical relational queries (ie, the relational
data can be meaningfully represented hierarchically, via level and
heritage (specifically, parent) data), and which allows xml-conversion
of relational data, but that unfortunately 'flattens' the hierarchical
relational data in the process of converting that relational data to
XML.  So, in order to do this, I need to have the 'utility' elements
that I identified (LEVEL_, ROWID_ and PARENTROWID_ - that establish the
depth/heritage in the hierarchy [sidebar: in all actuality, I just need
to identify those that are top-level and those that aren't - which now
occurs to me that I could do simply based on the presence/absence of a
PARENTROWID_ element - but Oracle's CONNECT BY query produces a 'level'
value t!
 hat fits the bill nicely] and then I want to be able to generically
're-constitute' the hierarchical nature of _any_ data that is generated
via the CONNECT BY (herarchical relational) query (but that is
subsequently squashed flat by the XML conversion process).  Thus, I
can't reference 'data' elements in the stylesheet (like NODE, SRCD,
etc), as I don't know what those will actually be in the generic/runtime
use of the stylesheet - I can only rely on the presence of these
'utility' elements that I have predicated as requirements for anyone
wishing to use this 'reconstitution' service.

So, any further info/advice that you can provide in the context of this
generic/service approach to the problem would be most welcome!

Thanks for the help!!

Jim

Current Thread