FOSI - multiple levels of logic testing

[ptc-953343]

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

[PaulGrosso]

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

[ptc-1908075]

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-----

[DavidS.Taylor]

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

[ptc-953343]

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
>

[naglists]

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.

[ptc-953343]

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

[ptc-1908075]

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

[LynnHales]

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

[ptc-953343]

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
>
>

[LynnHales]

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

[steve.thompson4]

I'm definitely with Lynn on that one. I only use the panels when there's any question which e-i-c is actually being triggered by the context. The engine occasionally picks a slightly different interpretation of context than seems obvious, at least to me.


Steve Thompson
+1(316)977-0515

[ebenton]

On the other hand, editing in tagged mode and with the panels prevents you from creating typos. You can't accidentally leave out any quotation marks or angle brackets.

[steve.thompson4]

Sorry. I was insufficiently explicit. My editing is primarily tagged mode. Anything else, including the "in Context" panels, is strictly in support of that mode. Thoroughly agree about the safeguards of tagged mode.


Steve Thompson
+1(316)977-0515

[ptc-1908075]

Both FOSI interfaces have their strengths. In my experience, utilizing the best
of both can make FOSI development and maintenance faster and easier.

The FOSI style panels interface has several very nice features that are not
available with the tagged editor:
* You can start a style panel from the document in order to see easily exactly
which e-i-c is being matched. This can be a huge time saver.
* You can find the next element(s) in the document that match(es) the element
in the style panel.
* Using Resolve in a style panel traces the source of each characteristic value
in the e-i-c and enables display of their style panels, which is another huge
time saver.
* You can use the Query menu in the All FOSI Components panel and the All
Elements-in-Context panel to find elements by name or expression and list them
in a separate panel, from which you can start a panel for the desired e-i-cs.
* The Query menu has an item to find and list all e-i-cs in the FOSI that do
not match elements in the DTD (which makes them pseudo-elements). Check this
list for typos that could be turning DTD elements into pseudo-elements.
* Another Query item finds all DTD elements that do not have e-i-cs in the
FOSI. If nothing is listed, maybe the FOSI is finished 🙂
* You can be in more than one place in the FOSI at the same time. For example,
you can display panels for All Counters, All Text Variables, All
Elements-in-Context, All Float Locations, on screen at the same time. This
eliminates a lot of time-consuming scrolling in the tagged editor.
* The page layout panels are helpful in understanding and coding pagesets,
quintuples, and anything else page-related. The calculation capability is great!
It shows the calculated flowtext depth and also indicates when a change to a
page layout value requires a re-calculation.
* You can link from a style panel to the corresponding place in the tagged
editor.
The FOSI tagged editor has its own features, some of which are necessary but not
available in the style panels interface:
* Entities can be declared, displayed, counted, and found.
* Some things can only be entered in the tagged editor, such as specifying
gitype.
* The tagged FOSI editor is based on the Editor, with similar menus.
* As in the Editor, ACL can be entered or sourced at the command line to
manipulate the tagged FOSI just like a document in the Editor. For example,
keymappings, while loops, etc., can be used to make repetitive changes.
* The Show Ids panel is very useful for fixing completeness and compile errors;
locating each use of charsubsets, counters, strings, float locations, etc.;
finding string variables that are not declared and initialized.
* A FOSI in the tagged editor can be formatted with a FOSI. I use this
capability to highlight stuff such as variables with certain names; categories
such as Reset; Specvals that apply only to the Edit window display; etc.
Sometimes, though, an ascii editor is the quickest way to go; for example, when
you want to change the name of a variable or charsubset or whatever that is used
dozens or hundreds of times in a FOSI. Just take care not to do anything that
will make the FOSI out of context.

Suzanne

[ptc-953343]

I like having the FOSI panels available. If nothing else they make a FOSI
more readable. Somethings are still hidden and tricky to get to, and
eventually you just get too many panels open. As Suzanne mentions there
are a lot of nice features that can make life easier.

BUT as I start to take advanatage of standard things like entities, the
panels stop displaying information.

I switch to the tagged view when doing big changes and also use TextPad.
Problen with direct editing in textpad is if you use some of the other
editors the file gets locked.

So yes, each has its place in my day to day work 😉

..dan


> Both FOSI interfaces have their strengths. In my experience, utilizing the
> best
> of both can make FOSI development and maintenance faster and easier.
>
> The FOSI style panels interface has several very nice features that are
> not
> available with the tagged editor:
> * You can start a style panel from the document in order to see easily
> exactly
> which e-i-c is being matched. This can be a huge time saver.
> * You can find the next element(s) in the document that match(es) the
> element
> in the style panel.
> * Using Resolve in a style panel traces the source of each characteristic
> value
> in the e-i-c and enables display of their style panels, which is another
> huge
> time saver.
> * You can use the Query menu in the All FOSI Components panel and the All
> Elements-in-Context panel to find elements by name or expression and list
> them
> in a separate panel, from which you can start a panel for the desired
> e-i-cs.
> * The Query menu has an item to find and list all e-i-cs in the FOSI that
> do
> not match elements in the DTD (which makes them pseudo-elements). Check
> this
> list for typos that could be turning DTD elements into pseudo-elements.
> * Another Query item finds all DTD elements that do not have e-i-cs in
> the
> FOSI. If nothing is listed, maybe the FOSI is finished 🙂
> * You can be in more than one place in the FOSI at the same time. For
> example,
> you can display panels for All Counters, All Text Variables, All
> Elements-in-Context, All Float Locations, on screen at the same time. This
> eliminates a lot of time-consuming scrolling in the tagged editor.
> * The page layout panels are helpful in understanding and coding
> pagesets,
> quintuples, and anything else page-related. The calculation capability is
> great!
> It shows the calculated flowtext depth and also indicates when a change to
> a
> page layout value requires a re-calculation.
> * You can link from a style panel to the corresponding place in the
> tagged
> editor.
> The FOSI tagged editor has its own features, some of which are necessary
> but not
> available in the style panels interface:
> * Entities can be declared, displayed, counted, and found.
> * Some things can only be entered in the tagged editor, such as
> specifying
> gitype.
> * The tagged FOSI editor is based on the Editor, with similar menus.
> * As in the Editor, ACL can be entered or sourced at the command line to
> manipulate the tagged FOSI just like a document in the Editor. For
> example,
> keymappings, while loops, etc., can be used to make repetitive changes.
> * The Show Ids panel is very useful for fixing completeness and compile
> errors;
> locating each use of charsubsets, counters, strings, float locations,
> etc.;
> finding string variables that are not declared and initialized.
> * A FOSI in the tagged editor can be formatted with a FOSI. I use this
> capability to highlight stuff such as variables with certain names;
> categories
> such as Reset; Specvals that apply only to the Edit window display; etc.
> Sometimes, though, an ascii editor is the quickest way to go; for example,
> when
> you want to change the name of a variable or charsubset or whatever that
> is used
> dozens or hundreds of times in a FOSI. Just take care not to do anything
> that
> will make the FOSI out of context.
>
> Suzanne
>

[ptc-953343]

At 07:27 PM 8/22/2010, you wrote:
>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.

So to extract this back to the original question. For all the
possible combinations of tests that I might need for my 10
configurations with 3 different options, I would at the top level do
those tests and create an element that flags if present (or not).

Then later at the individual element level where I need to check the
state I would just look for the presence of a given element? I don't
know if this simplifies things or not. I maybe reducing some of the
logic, but it still seems like I have to check now for one of these
elements. So if I had 30 conditions I was tracking, I would do that
complex logic at the top level once, but at individual elements in
the body, I still might have 30 conditions to check. At the element
level I guess I might be down to a yes/no test so that instead of all
the logic being repeated and tested all over the place.

Is that what is being recommended? I don't see how I can remove all
the tests when I finally need the formatting information, but I can
see that maybe this simplifies things.

So is there an easy way to debug/test pseudo elements? What I mean is
can I display them to see if they are in-line and in situations where
they have content show that content? I'm worried that I might be
thinking they are set and their not or worst, I have a typo somewhere
that prevents something from working - done that a few times even
with regular elements or contexts 😉

..dan
---------------------------------------------------------------------------
Danny Vint

Panoramic Photography

[DavidS.Taylor]

Hi Dan,

Referring to the brief example Suzanne sent last Sunday, the purpose of testing for your configuration and options at the top level can go beyond just setting a flag. It's possible to set up the category and characteristic parameters that need to be different for each output right at the start, using string variables and pseudo-elements. At the e-i-c where a different output format is needed, there is no test required. The category and/or characteristic values are filled by referencing the variables and pseudo-elements set up at the top level.

In the example, the <toptag> 'type' attribute determines which pseudo-element is called when 'variable.txt' is used in <childelement1> or <childelement2>. They don't require any attribute rules to determine what to output.

Hopefully you can apply this to your situation, even though the example is necessarily limited. This is also an illustration of why it is sometimes necessary to work in the FOSI tag view. Doing this using the panels could be much more difficult to follow.

I work in the tag view 95% of the time as I find it much faster. The panel view is very useful for testing and troubleshooting when something isn't coming out as expected.

Hope this helps a bit more.

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

[ptc-1908075]

You are on the right track. Keep trying to find ways to avoid as many test as
you can because too many atts really slow down the formatting speed.

[JasonBuss]

I have been using tagged view for most of my FOSI editing; I do use a
lot of entities in the FOSI and you can have trouble seeing (and
editing) them from the panels.

But yes, the panels are great for troubleshooting and finding the e-i-c
being triggered for the element you're trying to format.

One caveat with the style panels (this may be isolated to 5.3), if you
are trying to copy and paste a pageset quint, sometimes the panels get
screwy and you can lose a whole pageset (I have cursed this more than
once).

So, based on my experiences with the FOSI panels, working in
pagesets/pagespecs is MUCH safer in tagged mode or ASCII editor.

-Jason