[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Advice/feedback on stylesheet?
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: 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|