1-Visitor

Question

FOSI - multiple levels of logic testing

Forum|Forum|15 years ago
August 19, 2010
19 replies
3029 views

I'm running into a situation where the programmer in me wants to use a
structure that would look like this:

if ((type='checklist') and (foo='1' or foo='2' or foo='3')) then ...

Attribute rules seem to be the place to do this but they don't nest. I
think I've worked around this in a case or two by introducing
pseudo-elements so I can split some of this processing out. Is this my
only option? that seems like a complicated workaround for something that
is so easy to express.

My problem is that I have an existing stylesheet that is fairly complete
but it only formats the tech manaul. Not sure how they intended to handle
all the possible variations that are required. I want to leverage this
stylesheet to make a checklist version that has a few things different in
presentation, primary one being the page size, but there are also some
numbering and linking differences as well. This impacts a fair number of
elements and is getting out of hand.

I have been working with 2 levels of logic, but now I found a requirement
for a third, not sure what else I might find.

I've also thought about creating 2 stylesheets and sharing some of the
common element definitions. This works well with the tagged FOSI view, but
entities don't work well in the other FOSI panels. Maybe I just have to
bite the bullet here and start carving thsi stylesheet up?

Any ideas are appreciated.

thanks
..dan

P

PaulGrosso

1-Visitor

Starting in 5.4, we have added a "testgroup" element to
our outspec.dtd. See help 11006. See if that gives you
what you want.

paul

P

ptc-1908075

1-Visitor

The following approach should work as long as the "whatever" charsubset does not
include any repeating categories (except Reset and unappended Savetexts).

att logic=and
specval attloc=[element-name] attname=type attval=checklist
specval attloc=#FOSI attname=foo attval=1
charsubset charsubsetref=whatever
...
att logic=and
specval attloc=[element-name] attname=type attval=checklist
specval attloc=#FOSI attname=foo attval=2
charsubset charsubsetref=whatever
...
att logic=and
specval attloc=[element-name] attname=type attval=checklist
specval attloc=#FOSI attname=foo attval=3
charsubset charsubsetref=whatever
...

Suzanne

-----End Original Message-----

D

DavidS.Taylor

1-Visitor

I don't know if this would apply in your situation, but have you considered implementing the variations using some set-up strategy at the start of your FOSI? I use this to allow the same FOSI to output both English and French formatted documents.

One example is numbering in the document; our English documents use 1.2.3.4.(1)(a)(i), French ones use 1.2.3.4. 1) a) i) where the spacing before the sentence, clause and subclause numbering is not a left parenthesis as in the English but 'space' equal to the width of a left parenthesis. Declaring a savetext and setting it when the top-level element is processed to either "(" or "0.17em" based on the document language, all e-i-c characteristics dealing with numbering don't require attribute rules to deal with the language formatting differences.

The same method works for many frequently generated words and phrases, as well as for changing pagesets and setting formatting dimensional values that must be different in the two languages. The reduction in the number of e-i-c attribute rules required is significant.

FWIW...

Cheers,

David

David S. Taylor

Project Manager, Structured Information
Institute for Research in Construction
National Research Council Canada
Bldg. M-23A, Room 239
1200 Montreal Road, Ottawa, ON K1A 0R6

P

ptc-953343

Author

1-Visitor

Not sure if you are doing something more complicated. The simple yes/no
test (English/French) isn't the problem, it is when that test has to be
combined based upon some other attribute further into the document. Maybe
I missed something in your explanation.

So in my case I have an attribute at the top level that is the manual type
(of which there are 10 possibilities). So that helps me set page size and
stuff. But this same attribute is also used in other decisisions which
have their own range of possibilities.

So an example of that is when type=manaul, I get the typical part chapter
section numbering scheme. When it is a checklist, all numbering is
removed, the part title doesn't output the same way, the chapter title is
not produced in the same location. Instead it concatenates with the first
section in the chapter. This new heading is then formatted with a bounding
box, white text on a black background for the section title, but the
chapter title is black text on white background. This is an example where
I used a psuedo element for the title and heading together and put some of
the processing there.

The number of tests and combinations are growing. I like keeping the code
all together, so it bothers me to split this logic up and to also have it
now contained in at least two different eics.

Looks like I might be abel to switch to 5.4 so that new feature may do the
trick and supports the way I think about the processing.

thanks

..dan

> I don't know if this would apply in your situation, but have you
> considered implementing the variations using some set-up strategy at the
> start of your FOSI? I use this to allow the same FOSI to output both
> English and French formatted documents.
>
> One example is numbering in the document; our English documents use
> 1.2.3.4.(1)(a)(i), French ones use 1.2.3.4. 1) a) i) where the spacing
> before the sentence, clause and subclause numbering is not a left
> parenthesis as in the English but 'space' equal to the width of a left
> parenthesis. Declaring a savetext and setting it when the top-level
> element is processed to either "(" or "0.17em" based on the document
> language, all e-i-c characteristics dealing with numbering don't require
> attribute rules to deal with the language formatting differences.
>
> The same method works for many frequently generated words and phrases, as
> well as for changing pagesets and setting formatting dimensional values
> that must be different in the two languages. The reduction in the number
> of e-i-c attribute rules required is significant.
>
> FWIW...
>
> Cheers,
>
> David
>
> David S. Taylor
>
> Project Manager, Structured Information
> Institute for Research in Construction
> National Research Council Canada
> Bldg. M-23A, Room 239
> 1200 Montreal Road, Ottawa, ON K1A 0R6
>

N

naglists

1-Visitor

Dan,
I feel your pain. I have similar requirements and I have resorted to a mix
of some of the suggested solutions, but ultimately, I have not been able to
avoid "fields of <att> stretching as far as the eye can see." All I can say
is that if you're going down that road, you really must consider using a
text editor for some of that work.

For example, you set up your "base" set of <att>s, lets say 12 that cover
all variations on all conditions but is specific to one variation of your
last condition. Copy paste that block into a separate instance of your text
editor. Find/Replace on that last condition so it now reflects the second
variation of that condition. Copy/paste that block into the FOSI. Flip back
to the separate instance. Undo the find/replace. Find/replace on the third
variation..... you get the idea.

Tedious. But better, I think, than trying to manage your 48 or 96 or ...
separate <att>s in Architect. (Although, I confess, I am no Architect guru,
maybe it's more flexible than I think in this regard.)

Further, when your customer discovers something "interesting" late in the
game, a text editor find and replace across this field of <att>s is fairly
quick/painless compared to what I imagine you'd have to do within Architect.

P

ptc-953343

Author

1-Visitor

I've been switching back and forth between Architect and text pad. As
I use more entities to manage content, it is becoming less useful. It
appears the FOSI panels do not always expand the content.

There are some nice features in Architect for finding content and
checking context that I like. I'll have to check on Paul's suggestion
and extension - any guess if it is supported in the panels 😉 probably not.

..dan

P

ptc-1908075

1-Visitor

I think David is on the right track about setting things up at the document
level whenever possible. With this approach, attribute testing is performed
once, eliminating the need for lots of attribute testing in lots of e-i-cs. This
may be opposite to the way it would be done in XSL. However, in FOSI, the one
thing that will negatively affect FOSI performance is too many attribute tests
and/or system-funcs.

Taking David's example one step further, you can use string variables and
pseudo-elements at the top level to support conditions later in the document.
One of the possibilities is shown in the following example. The output from the
usetexts in <childelement1> and <childelement2> depends on the attribute
settings on <toptag>. This technique can be extended to other FOSI categories.

e-i-c gi="toptag"
att
specval attloc="toptag" attname="type" attval="A"
charsubset
savetext textid="variable.txt" conrule="<a.psu>,</a.psu>"
att
specval attloc="toptag" attname="type" attval= "B"
charsubset
savetext textid="variable.txt" conrule="<b.psu>,</b.psu>"

e-i-c gi="childelement1"
usetext source="variable.txt"

e-i-c gi="childelement2"
usetext source="variable.txt"

e-i-c gi="A.psu"
usetext source="\Something\"

e-i-c gi="B.psu"
usetext source="\Something else\"

Suzanne

L

LynnHales

1-Visitor

Dan,

Another thing to consider for numerous <att>s, especially if any are reused,
is to make them an ENTITY reference. You are still faced with having the
logic in two places (more or less), but it is managed only in the ENTITY
text.

This won't work too well if each <att> is unique, but if there are more than
two with the same logic in different <e-i-c>s this may be something to
consider. Archaic, but it works.

Lynn

P

ptc-953343

Author

1-Visitor

This is the method I have tried so far. I wasn't able to take the entire
set as is, but I was able to use some of my tests as entities. Problem is
that the FOSI panels do not support the use of entities so the actual test
values do not show up.

thanks

..dan

> Dan,
>
>
>
> Another thing to consider for numerous <att>s, especially if any are
> reused,
> is to make them an ENTITY reference. You are still faced with having the
> logic in two places (more or less), but it is managed only in the ENTITY
> text.
>
>
> This won't work too well if each <att> is unique, but if there are more
> than
> two with the same logic in different <e-i-c>s this may be something to
> consider. Archaic, but it works.
>
>
>
> Lynn
>
>

L

LynnHales

1-Visitor

FOSI panels, oh yes I think I saw those once. 🙂

Me, I'm a glutton for punishment, I use the edit in tagged mode (or
sometimes even the more archaic brute force method of the ASCII itself).

Seriously you may want to look at editing the FOSI in tagged mode as you do
have more functionality than with the panels (at least I think so).

Lynn

Show more replies

Sign up

Please use your PTC eSupport account.

Welcome to the PTC Community

Please use your PTC eSupport account.

Scanning file for viruses.

This file cannot be downloaded