cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Did you get called away in the middle of writing a post? Don't worry you can find your unfinished post later in the Drafts section of your profile page. X

still struggling with FOSI mindset

ptc-953343
1-Newbie

still struggling with FOSI mindset

I'm still trying to get FOSI with my XSLT orientation.

I have the following XML

<procedure>

<step>

<challenge>this is a challenge</challenge>

<para>First para in a step but with a challenge preceeding sibling</para>

</step>

<step>

<para>This is a para with no sibling, truly the first child of step</para>

</step>

</procedure>

So how can I apply different formatting to the second para in step 2, than the para in step 1? In both cases they are occurence= first so that test doesn't work. In XLST I would check to see if there was a preceeding-sibling, what is the best way to detect this in FOSI?

..dan

13 REPLIES 13


Hi Dan,
May be you can test on <step>...
Plamen

sorry that is a little too cryptic. If your thinking there is something
different about the first step, there isn't. Step can have either a
challenge or a para starting it, with paras allowed to repeat within the
step.

..dan

>
> Hi Dan,
> May be you can test on <step>...
> Plamen

first para context of first step


Initialize a text variable, isfirst_instep.txt to "no" in string decl:
<stringdecl textid="isfirst_instep.txt" literal="no">

Flip the textvar's value on steps:
in e-i-c gi="step" occur="first" set isfirst_instep.txt = "yes"
placemnt="before"
in e-i-c gi="step" occur="notfirst" set isfirst_instep.txt = "no"
placemnt="before"

Then on all the elements that might occur in step:
in e-i-c gi="para" context="step"
in e-i-c gi="challenge" context="step"

do an attribute test:
specval attname="isfirst_instep.txt" attloc="#FOSI" attval="yes"
then do that first thing AND set isfirst_instep ="no"

and another attribute test:
specval attname="isfirst_instep.txt" attloc="#FOSI" attval="no"
do that notfirst thing

Notes:
1) Be sure to follow or establish a "style" re: whether you use: Yes/No,
yes/no, or, I suppose, YES/NO for this sort of thing. You do NOT want to
debug a FOSI where you have to remember in which situations you used
Yes/yes/YES.

2) Consider whether the first para in the first step needs to process
differently from the second para in the first stip (assuming your DTD
permits multiple paras). The pseudo code above doesn't differentiate.

3) Some things you may not need to do on para within a first step, you might
be able to do them on procedure, especially if you're talking about
numbering.

4) The above could be a bad idea depending on the content model of step. It
may be the right thing to do to the type of test you want (for next/previous
siblings) which you can do with a system-func calling an ACL that did
something with oid_prev(). We use this function for a similar test where we
evaluate the actual previous or next sibling's element name:

function nextsib(win,oid) {
return oid_name(oid_next($oid))
}
function prevsib(win,oid) {
return oid_name(oid_prev($oid))
}

I think the win var is only required when it is being called from the FOSI.
If you wanted to test this in Editor, you would use something like:
response(oid_name(oid_next(oid_caret()))

All previous caveats about system funcs apply: in certain conditions, they
can cripple the processor during formatting. As I recall, this one is pretty
gentle (especially since your context is going to be fairly limited).

Dan,
I agree with most of what Paul sent. However, I don't believe he 'got' your requirement fully, and I have a suggestion just as good programming form...

The following is his version:
Flip the textvar's value on steps:
in e-i-c gi="step" occur="first" set isfirst_instep.txt = "yes" placemnt="before"
in e-i-c gi="step" occur="notfirst" set isfirst_instep.txt = "no" placemnt="before"

It's last line is not necessary unless you have some other reason to have a "step" "notfirst", and would be incorrect even in that case. You don't need a "first/notfirst" for this. Looks to me like your example wants to determine whether <para> is first in <step>, not whether <para> is in first <step>. If so, you need this in EVERY "step" gi:
set isfirst_instep.txt = "yes" placemnt="before"
In the "para" and "challenge" gi's, do the attribute tests indicated, but do the attval "no" test first. Current experience is that the changing of the value in isfirst_instep.txt in the "yes" test won't be seen by the "no" test, but some future update of Editor could include the 'correction' of that inconsistent behavior. That is, it could become possible to actually test the value of a text variable that was set at some 'earlier' point in the same gi. For that reason, it seems prudent to me to do the tests in the other order.

Regards to You Both,
Steve Thompson
TAD Technical
Boeing-IDS Technical Publications
+1(316)977-0515
MC K83-08
The truth is the truth even if nobody believes it, and a lie is a lie even if everyone believes it.

NOTICE: This communication may contain proprietary or other confidential information. If you are not the intended recipient, or believe that you have received this communication in error, please do not print, copy, retransmit, disseminate, or otherwise use the information. Also, please indicate to the sender that you have received this e-mail in error, and delete the copy you received. Any and all views expressed are the current understanding of the sender and should not be interpreted as an expression of official Boeing Company policy or position.

Les renseignements contenus dans ce message peuvent être confidentiels. Si vous n'êtes pas le destinataire visé ou une personne autorisée à lui remettre ce courriel, vous êtes par la présente avisé qu'il est strictement interdit d'utiliser, de copier ou de distribuer ce courriel, de dévoiler la teneur de ce message ou de prendre quelque mesure fondée sur l'information contenue. Vous êtes donc prié d'aviser immédiatement l'expéditeur de cette erreur et de détruire ce message sans garder de copie.

Thanks everyone I'll give this a try. Steve your right I'm trying to
control the para inside of the step element. this certainly is the
roundabout way to deterine something so easy.

Has anyone worked with the XPath extension to the FOSI language that
Arbortext has implemented? I came across some info I think in the
annotated spec but it didn't have any useful example of how and why I
would use it. Seems like my XSLT bent might fit that better. If you have
used this extension, what have you seen in the way of a performance hit?

..dan

> Dan,
> I agree with most of what Paul sent. However, I don't believe he 'got'
> your requirement fully, and I have a suggestion just as good programming
> form...
>
> The following is his version:
> Flip the textvar's value on steps:
> in e-i-c gi="step" occur="first" set isfirst_instep.txt = "yes"
> placemnt="before"
> in e-i-c gi="step" occur="notfirst" set isfirst_instep.txt = "no"
> placemnt="before"
>
> It's last line is not necessary unless you have some other reason to have
> a "step" "notfirst", and would be incorrect even in that case. You don't
> need a "first/notfirst" for this. Looks to me like your example wants to
> determine whether <para> is first in <step>, not whether <para> is in
> first <step>. If so, you need this in EVERY "step" gi:
> set isfirst_instep.txt = "yes" placemnt="before"
> In the "para" and "challenge" gi's, do the attribute tests indicated, but
> do the attval "no" test first. Current experience is that the changing of
> the value in isfirst_instep.txt in the "yes" test won't be seen by the
> "no" test, but some future update of Editor could include the 'correction'
> of that inconsistent behavior. That is, it could become possible to
> actually test the value of a text variable that was set at some 'earlier'
> point in the same gi. For that reason, it seems prudent to me to do the
> tests in the other order.
>
> Regards to You Both,
> Steve Thompson
> TAD Technical
> Boeing-IDS Technical Publications
> +1(316)977-0515
> MC K83-08
> The truth is the truth even if nobody believes it, and a lie is a lie even
> if everyone believes it.
>
> NOTICE: This communication may contain proprietary or other confidential
> information. If you are not the intended recipient, or believe that you
> have received this communication in error, please do not print, copy,
> retransmit, disseminate, or otherwise use the information. Also, please
> indicate to the sender that you have received this e-mail in error, and
> delete the copy you received. Any and all views expressed are the current
> understanding of the sender and should not be interpreted as an expression
> of official Boeing Company policy or position.
>
> Les renseignements contenus dans ce message peuvent être confidentiels. Si
> vous n'êtes pas le destinataire visé ou une personne autorisée à lui
> remettre ce courriel, vous êtes par la présente avisé qu'il est
> strictement interdit d'utiliser, de copier ou de distribuer ce courriel,
> de dévoiler la teneur de ce message ou de prendre quelque mesure fondée
> sur l'information contenue. Vous êtes donc prié d'aviser immédiatement
> l'expéditeur de cette erreur et de détruire ce message sans garder de
> copie.
>
>

Dan,

Looks like I didn't need the special formatting. I inherited this
FOSI and the way the numbers were assigned to the list items was
throwing off the indents. I may still need an alignment group but I
got past the problem.

I'm still interested if anyone has mande use of the XPath extension for FOSIs.

..dan



We've used XPath, but only in ACL. Using it directly in the FOSI completely changes the paradigm, in a not convenient or flexible way, in my opinion.

Your Subject is correct. It's a different mindset. Switching back and forth takes a little practice, but it does work and there are advantages to both.

Steve Thompson
+1(316)977-0515

Its been awhile since I found it in the spec, I was unclear as to how it
would even be applied. My assumption was that it replaced the context
information and posibly the occurance.

I'm slowly digging into the spec and the documentation but it is not easy
pulling it all together. PTC is probably not interested in FOSI specific
help now that they have Styler but it wure would be nice to have all the
help topics and the spec information combined into a single manual that
you could search directly and not have it pull up un related topics.

I've already found or rediscovered some features in the FOSI panels that I
was unaware.

..dan


>
> We've used XPath, but only in ACL. Using it directly in the FOSI
> completely changes the paradigm, in a not convenient or flexible way, in
> my opinion.
>
> Your Subject is correct. It's a different mindset. Switching back and
> forth takes a little practice, but it does work and there are advantages
> to both.
>
> Steve Thompson
> +1(316)977-0515
>

Steve,

I think you are right on target. If XPath is needed, do it through ACL.

FWIW: I have been working with FOSI since 1992 and have never needed XPath. Once or twice I have used SYSTEM-FUNC and some ACL to get something from the tree in order to process it in some way and return the result to the FOSI, but that's it.

Suzanne





----------

Hi Suzanne,

Would you mind explaining why you hold this opinion regarding xpath in fosi
ie. "Using it directly in the FOSI completely changes the paradigm, in a
not convenient or flexible way...."

As I understand it to use xpath in fosi we just need to set the attloc
to #xpath, and the attname to the required path....
Are there problems with this method, performance or otherwise?


thankyou,
Tracey Orso



On Thu, Jun 10, 2010 at 9:46 AM, Suzanne Napoleon <
SuzanneNapoleon@fosiexpert.com> wrote:

> Steve,
>
> I think you are right on target. If XPath is needed, do it through ACL.
>
> FWIW: I have been working with FOSI since 1992 and have never needed XPath.
> Once or twice I have used SYSTEM-FUNC and some ACL to get something from the
> tree in order to process it in some way and return the result to the FOSI,
> but that's it.
>
> Suzanne
>
>

Tracey,
Actually, that was me expressing that opinion. Suzanne just agreed.

The "changes the paradigm" part is not opinion. To use XPath directly, you must change a setting that causes the FOSI to be processed in the order the e-i-c's are listed. That is completely different than the usual, which is to process the FOSI based on the best match found for the context and occurrence.

From that, it directly follows that one is much more constrained in structuring the e-i-c's, and the order becomes of nearly primary importance. In some contexts, one order might be best, while in another, that order is inconvenient, to say the least. Thus, "not convenient or flexible".

My Two Cents,
Steve Thompson
+1(316)977-0515
----------
Top Tags