Re: Help needed in recursively converting the flat xml to a heirarchical XML
2004-03-29 11:10:34
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(_at_)mulberrytech(_dot_)com
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
======================================================================
|
|