Cart
|
[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Re:Help needed in recursively converting the flat
 At 02:07 PM 3/30/2004, you wrote: I think I made a significant progress with your explanation. Thanks, But still I am stuck with some problems. Ah, well if you need the logic to say "pick up a join unless it's being picked up by some other transition", that's a bit more complicated. You need a test or a filter on the candidate join (the one you are considering picking up) to establish whether it is one you actually want or not. This suggests each join be able to know which transition it "belongs to". This is not impossible (again, keys provide facilities for this kind of test), but the exact syntax depends on the exact logic you want to express. 2. As I said there can be nested <concurrent-block> structures one inside the other. Though I am able to populate this structure with my code, the problem here I am facing is the internal <concurrent-block> is also being populated at the external level. The problem is I am using a for each select = "fork" at the template level which will loop through all the <concurrrent-block> structures in the original xml. But I am not able to figure out the solution. I'm not sure I follow here. It looks like you may be describing the problem of preventing concurrent-blocks from being handled by the straight (default) node traversal performed by the processor, which I addressed last time by suggesting empty templates you could use to suppress them. But I can't tell for sure. Maybe you need to isolate this problem by showing us just the bit of code that is doing this now, with its results and with an explanation of what you want its results to be. Help us help you, in other words. (Most of us helper-types also have day jobs and don't have the time to reconstruct the problem with your requirements. Sometimes we can spot problems anyway, but yours is a complicated case.) 3. The example I pasted here is fairly a simple one, which does not have multiple <activity-state> nodes inside a <concurrent-block> I think you can handle this by extending the kind of processing you are already doing. Establish the retrieval requirements precisely, and express them through key declarations that will let you retrieve just the nodes you want from the context where you want them. It is interesting how easy it is to find a solution once the problem is properly and fully defined. Maybe you need to down-shift. Intead of posing the general question of "how do I accomplish X", you could try posting more focused questions, such as "I expect this bit of code to do Y, but it does Z: why?" That might help get you get to your goal more quickly while at the same time bringing the deeper questions to light. Cheers, Wendell
|
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
|
