Re: [xsl] Help needed in recursively converting the flat xml to a heirarchical XML

Subject: Re: [xsl] Help needed in recursively converting the flat xml to a heirarchical XML
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Mon, 29 Mar 2004 13:10:34 -0500
Sridhar,

Thanks for the update.

Clarification of the spec is a critical first step, but you need to take it farther than that. Sure, given input and a complete spec of the problem, someone on this list could take a few minutes or an hour or two to write and test your stylesheet, but is that what you really want? (It might help hone your skills at, erm, finding solutions, but it wouldn't really help you learn XSLT, would it?) If you want our help with your XSLT, you really need to provide us with some to work with.

Could you show us your XSLT stylesheet so far, or if you have none, could you suggest where you are getting stuck in creating one?

We welcome beginner questions, but we also expect you will be doing some homework -- looking at resources on line and in print to guide you, trying things out, studying how XSLT processors work with simpler problems. Since your problem isn't a problem for beginners, it's understandable if you can't see the solution right off. But we can't really help unless we have some idea of how far you're getting and where you're running into difficulties. It's like your asking "how I move 60 cases of wine from Baltimore to Denver?" We can say, "in a truck, take I-70" (a big US superhighway), and we might even be able to suggest how you want to load and stack the cases for this delicate operation. But if you don't know how to start the truck and how the gear shift works, you really need to learn that, don't you?

Now maybe a helpful list contributor will just write your stylesheet. That'd be good, for you -- at least until you have another XSLT problem and haven't learned how the first one got solved.

Could you post again with your sample source data, your sample output, the rules you have articulated (copied below), and the stylesheet you have so far?

Thanks,
Wendell

Here is the exact logic for nesting of the nodes...

1. As you can see my input xml consists of <concurrent-block/fork/transition> nodes which has attribute value (@to). I have to look for all the <activity-state> nodes with the same value in (@name), and if matched, move the <activity-state> to <concurrent-block>, else I have retain them at the same place.

2. Secondly, inturn the <activity-state> also has <transition> node which can have values related to another <activity-state> node and/or <join> node or <concurrent-block> node. If any matches are found then I have to move all of them to the <concurrent-block> node.

3. If a <concurrent-block> node is found in the second step, that has to have all the related <activity-state> nodes, <join> nodes etc., with in its block.

4. One or More <activity-state> nodes will refer to the same <join> node but I need only one occurance of the <join> irrespective of how many <activity-state> nodes are refering it. The basic rule is "Each <concurrent-block> should contain only one <join> node."



====================================================================== Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================

Current Thread