Sridhar,
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.
1. As you said, I tried replacing
<xsl:copy-of select="key('jname', $joinname)"/> with
<xsl:copy-of select="key('jname', $joinname)[1]"/> but the problem here
since I loop thru each activity-state whether I use your solution or not
it is copying multiple joins (coz each activity-state can have multiple
transitions and each activity-state may refer to the same join).
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>
In this example the relation is
<concurrent-block> ---> <activitiy-state>-----> <join>. Hence my code is
working fine except the above two problems.
But I can have a possible scenario like
<concurrent-block>---->
<activity-state>----><activity-state>----><decision>----><join>
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
======================================================================
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
======================================================================