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

FOSI

Highlighted
Newbie

FOSI

I write a new DTD in Document Architect and install it, but I can't see my new
doctype in the list in ADEPT Editor (when I try to create a new file).
What is wrong?

And where can I define stylesheets. I read that there is FOSI. But where con I
change Fonts and other layout aspects for the new DTD.

Annette
email: Annette.Kirschenbauer@db.com
Tags (2)
34 REPLIES 34
Highlighted

FOSI

You should modify the startup.cf file:

DTDDIR; DTDNAME; template; demo
with the following meaning:
Directory_of_your_DTD ; NAME _YOUR_DTD ;
name_of_template_file ; name_of_demo_file
Tis will create an entry in the new file list You may leave out the demo
entry.
Make sure that you have a file template.sgm (and demo.sgm if wanted)

To edit a FOSI make sure you have a compiled DTD where the option
AllowFosiMod is set to Yes in the DTD.atd file

Regards,

Martin Mollema

> ----------
Highlighted

Re: FOSI

Hi,

I am new to Epic Editor and FOSI. Is there any good reference material
or some online training to get started with FOSI?

Thanks,
--
Sundhar Annamalai
sundhar@onebox.com - email
Highlighted

Re: FOSI

Sundhar:

Arbortext has 2 training courses for FOSI development:

- FOSI Stylesheet Design Workshop, Part 1, which covers formatting that
affects both edit window display and print output

- FOSI Stylesheet Design Workshop, Part 2, which covers formatting that
affects only print output

You need to take both Parts 1 and 2 for print output, but only Part 1 for
edit window display.

The courses are available as self-paced tutorials at $300 each. To order,
please contact training@arbortext.com.

The classes are also taught at our offices in Ann Arbor, Michigan. The
scheulde is on our web site at:
Highlighted

Re: FOSI

Sundhar,

Other than MIL-PRF-28001 appendix B, I am not aware of any reference
material that goes into any depth on the FOSI. 28001 is available in PDF
form from a couple of sites on line. The current version is 28001C. Closer
to home, an annotated copy of 28001C Appendix B is available in the Epic on
line help files. Look in the Style Sheet area of the help. If it is like
Adept 8 and 9, it is buried as a second link. The other way to find it is
(for Adept 9) look in the tutorials folder in the Adept folder. There
should be a 28001C.sgm file. This file is marked to show what portions of
the OS DTD Arbortext supports.

A word of warning on Appendix B. This is a U.S. DOD specification. It
lays the ground rules for FOSI developement. There are very few examples.
On the plus side, it is the source document for the FOSI. If you are going
to publish paper, nearly everything (except the DOD security markings) will
apply. For screen displays, then you don't have to overly concern yourself
with the page information.

I noticed that Suzanne has already mentione the Arbortext courses on FOSI
development. For training, that is probably the only training you will
find.

Good luck.

Lynn E. Hales
Information Technology Consultant
lhales@csc.com
(757)262-3495

"Sundhar Annamalai" <sundhar@onebox.com>@arbortext.com on 10/31/2000
Highlighted

Re: FOSI

At 07:26 AM 11/1/00 -0500, you wrote:
>Sundhar,
>
>Other than MIL-PRF-28001 appendix B, I am not aware of any reference
>material that goes into any depth on the FOSI. 28001 is available in PDF
>form from a couple of sites on line. The current version is 28001C. Closer
>to home, an annotated copy of 28001C Appendix B is available in the Epic on
>line help files. Look in the Style Sheet area of the help. If it is like
>Adept 8 and 9, it is buried as a second link. The other way to find it is
>(for Adept 9) look in the tutorials folder in the Adept folder. There
>should be a 28001C.sgm file. This file is marked to show what portions of
>the OS DTD Arbortext supports.
>
>A word of warning on Appendix B. This is a U.S. DOD specification. It
>lays the ground rules for FOSI developement. There are very few examples.
>On the plus side, it is the source document for the FOSI. If you are going
>to publish paper, nearly everything (except the DOD security markings) will
>apply. For screen displays, then you don't have to overly concern yourself
>with the page information.

No part of the table description (tabdesc), or graphics description (grphdesc)
is supported. The security description (secdesc) is at least mostly supported.
It looks fully supported in the formatting support tables in the online help,
which are found at Stylesheets (FOSIs) -> Stylesheet technical information.
(I'm a little curious what is required for DOD security markings that isn't
handled.)

>I noticed that Suzanne has already mentione the Arbortext courses on FOSI
>development. For training, that is probably the only training you will
>find.
>
>Good luck.
>
>Lynn E. Hales
>Information Technology Consultant
>lhales@csc.com
>(757)262-3495
>
>
>
>
>
>
>"Sundhar Annamalai" <sundhar@onebox.com>@arbortext.com on 10/31/2000
>04:10:52 PM
>
>Please respond to adepters@arbortext.com
>
>Sent by: owner-adepters@arbortext.com
>
>
>To: adepters@arbortext.com
>cc:
>
>Subject: FOSI
>
>
>Hi,
>
>I am new to Epic Editor and FOSI. Is there any good reference material
>or some online training to get started with FOSI?
>
>Thanks,
>--
>Sundhar Annamalai
>sundhar@onebox.com - email
>
>
>
>__________________________________________________
>FREE voicemail, email, and fax...all in one place.
>Sign Up Now! http://www.onebox.com
>
>

---
Gary Grosso
ggrosso@arbortext.com
Arbortext, Inc.
Ann Arbor, MI, USA


Highlighted

Re: FOSI

Hi Lynn,

I see how what you said could be interpreted that way (now that
I reread it).

The main thing I wanted to point out is that people should not
read about the tabdesc or grphdesc unless their interest is
solely to combat insomnia.

Highlighted

Re: FOSI

Gary,

That's what I get for typing without really reading. It made perfectly
good sense to "me" when I typed it. I wasn't implying that <secdesc>
didn't work, more that for non DOD publishing <secdesc> isn't really
needed.

Lynn E. Hales
Information Technology Consultant
lhales@csc.com
(757)262-3495

"Gary P. Grosso" <gpg@arbortext.com>@arbortext.com on 11/01/2000 09:51:28
AM

Please respond to adepters@arbortext.com

Sent by: owner-adepters@arbortext.com
Highlighted

Re: FOSI

Lynn,

At one time in the past I thought that a companion guide, referred to as
MIL-HDBK-SGML, was being developed. Is there such an animal??

If not, there should be one that is example oriented. Hmmmm....maybe it's
time to spill this brain onto a web page. Ten years of FOSI's has to be
worth something.

Matt Voisard
Dayton OH
Highlighted

Re: FOSI

Matt is correct, there is a "companion" military handbook called
appropriately enough MIL-HDBK-28001. Both the specification and the
handbook are available in PDF format at:
Highlighted

Re: FOSI

How can I write FOSI rules based on sibling tags? For example: Below I
would like the color of the text within the content tags to be based on one
of its siblings (case - should be blue if the cite status is valid, stat -
should be red if the cite status is valid). Any suggestions? Thanks.

<cite><case></case><content>Blue text because this cite tag contains a case
tag</content></cite>

<cite><stat></stat><content>Red text because this cite tag contains a stat
tag</content></cite>

Thomas J. Hack
Lexis-Nexis
Dayton, OH
thomas.hack@lexis-nexis.com


Highlighted

Re: FOSI

I didn't test it, but somewthing like this might work:
Set a FOSI variable in the e-i-c for the (case | stat) element
and then use the value of that variable to set font color in
the content element.

e-i-c gi="cite"
charlist
savetext textid="contentclr.txt" conrule=" placemnt="before"

charlist
/e-i-c

e-i-c gi="case" context="cite"
charlist
savetext textid="contentclr.txt" conrule="blue">
/charlist
/e-i-c

e-i-c gi="stat" context="cite"
charlist
savetext textid="contentclr.txt" conrule="red">
/charlist
/e-i-c

e-i-c gi="content" context="cite"
charlist
...
/charlist
att
specval attname="contentclr.txt" attloc="#FOSI" attval="blue"
highlt fontclr="blue"
/att
att
specval attname="contentclr.txt" attloc="#FOSI" attval="red"
highlt fontclr="red"
/att
/e-i-c

Didn't test it, but this is where I would start.
-Andy

"Hack, Thomas J. (LNG)" wrote:
>
> How can I write FOSI rules based on sibling tags? For example: Below I
> would like the color of the text within the content tags to be based on one
> of its siblings (case - should be blue if the cite status is valid, stat -
> should be red if the cite status is valid). Any suggestions? Thanks.
>
> <cite><case></case><content>Blue text because this cite tag contains a case
> tag</content></cite>
>
> <cite><stat></stat><content>Red text because this cite tag contains a stat
> tag</content></cite>
>
> Thomas J. Hack
> Lexis-Nexis
> Dayton, OH
> thomas.hack@lexis-nexis.com

--
/* Andy Esslinger - Lockheed Martin Aeronautics Company
(817) 777 1590 LM Aero F-22 TOD (Technical Order Data)
This is a proprietary business e-mail address. Do NOT release
to any other party. #INCLUDE STANDARD DISCLAIMER */


Highlighted

Re: FOSI

Put a savetext in the e-i-c for <case>. For example, call it "case.txt".
Make the conrule some literal value, such as \case\.

In the e-i-c for <content>, put an att with a specval on the e-i-c that
reads like this:
<specval attname="case.txt" attloc="#FOSI" attval="#ANY"> Make the text
color blue for this att.

Have another specval that reads:
<specval attname="case.txt" attloc="#FOSI" attval="#NONE"> Make the text
color red for this att.

If there is no <case> tag, there will be no case.txt, which is the same as
#NONE.

You might have to reset case.txt to nothing (savetext conrule="\\") after
each <content> or <cite> to prevent subsequent non-<case>-containing <cite>
tags from thinking that case.txt has some value, based on carrying over the
value from a previous savetext.
Highlighted

Re: FOSI

There's two ways of doing this

1) set a counter in the e-i-c's for <case> and <stat>, e.g.
<enumerat increm="1" enumid="citestatus.ct" setvalue="0"> and test the
value in an <att> rule in <content>, e.g.
<att>
<specval attname="citestatus.ct" attloc="#FOSI" attval="#EQ#\1\">
<charsubset>

</charsubset>
</att>

2) Test if the previous sibling of <content> is <case> or <stat> via a call
to an external ACL function, e.g
<att>
<specval attname="PrevSiblingIsCase" attloc="system-func" attval="1">
<charsubset>

</charsubset>
</att>

<att>
<specval attname="PrevSiblingIsCase" attloc="system-func" attval="0">
<charsubset>

</charsubset>
</att>

I've only sketched out the approach here - check the help files on calling
an external ACL function for more details

Phil
Highlighted

Re: FOSI

Hi all,

I have this code in my Fosi file :

<e-i-c gi="toto">
<charlist charsubsetref="TypeInLine"></charlist>
<att><fillval attname="att1" fillcat="usetext" fillchar="source">
<charsubset></charsubset>
</att>
<att><fillval attname="att2" fillcat="usetext" fillchar="source">
<charsubset></charsubset>
</att>
</e-i-c>

This works fine but this does not generate a space beetween the 2
attributes.
How can I do that space generation ?
I try to insert this code <usetext source="\" \&quot;=" placemnt="before"> between
charsubset tag in the second <att> but this does not work.

thanks.


Highlighted

Re: FOSI

Christophe,

I can think of two ways to do this. One I am not sure will work, I looked
to see if I had an example to verify my thought train, but didn't; the
other I know does work, but will require some FOSI changes.

The first method is in the charsubset for the second (and any that follow),
add a usetext to the charsubset. In the usetext source add the space you
want. You can use the back slashes and the space bar, comma delimited
points, ems, picas, or other valid measurements. Test this first, if this
doesn't work, while still in this first idea, after the space values, add
#CONTENT(att2) and see if that will work.

If neither of those work, I know this process will. In the <fillval>s,
change the usetext source to individual savetexts. Then when you are ready
to use the attributes, you can enter a usetext with the textids and the
desired space values between them.

<fillval attname="att1" fillcat="savetext" fillchar="conrule">
<charsubset>
<savetext textid="att1.txt"></charsubset>
</att>
<fillval attname="att2" fillcat="savetext" fillchar="conrule">
<charsubset>
<savetext textid="att2.txt"></charsubset>
</att>
Then somewhere later

<usetext source="att1.txt,6pt,att2.txt">

Hope this helps a bit.

Lynn E. Hales
Information Technology Consultant
lhales@csc.com
(757) 262-3495

Christophe DION <cdion@jouve.fr>@arbortext.com on 09/13/2001 04:54:43 AM

Please respond to adepters@arbortext.com

Sent by: owner-adepters@arbortext.com
Highlighted

Re: FOSI

Hi all,

some questions about fosi file again :
1. Is it possible to define text as small-caps ? I can't find a predefined
style.
2. I tried this code in my fosi file :
<e-i-c gi="xxx">
<charlist inherit="1" charsubsetref="TypeInLine">
<suppress sup="1">
</charlist>
</e-i-c>

But the text is always there : I can't hide it. What am I doing wrong ?

thanks


Re: FOSI

For small caps, use:
<e-i-c gi="xxx">
<charlist inherit="1">

</charlist>
</e-i-c>

As for why the suppress doesn't work, it's probably because something is
conflicting with it. Probably the inherit="1" or maybe the
TypeInline charsubsetref. Try removing the inherit, and if that doesn't
work, check the TypeInline charsubsetref.
Highlighted

Re: FOSI

I forgot to mention something in my previous response. If your problem is
with printed output, then my previous response is OK. If your problem is
with the Editor view, then unless you set hidesupress=on, you will still be
able to see suppressed text on the screen.
Highlighted

Re: FOSI

Christophe,

Ed pretty much answered your second question. Though I will add a warning
to using the set hidesuppressed command. If you set hide suppressed to on,
then all the text, generated, author entered, or other wise, will be hidden
from view. This includes child elements. Test this before you implement.
For some reason or another, authors don't appreciate it when they can't see
what they are writing.

To answer your first question, can you implement small caps, the answer is
yes. There is an attribute in called 'smallcap'. It is a toggle
defaulted to off (0). Add font to your charlist, charsubset, or subchar
(depending where you are in the FOSI) and then modify the attributes and
set small cap to "1". I just tested this with Epic 4.1 and it does work
(better than this morning).

Lynn E. Hales
Information Technology Consultant
lhales@csc.com
(757) 262-3495


Christophe
DION <cdion to:=" &quot;adepters@arbortext.=" com&quot;=" <adepters@arbortext.com=">
@jouve.fr> cc:
Sent by: Subject: FOSI
owner-adepter
s


09/28/2001
12:06 PM
Please
respond to
adepters



Hi all,

some questions about fosi file again :
1. Is it possible to define text as small-caps ? I can't find a
predefined
style.
2. I tried this code in my fosi file :
<e-i-c gi="xxx">
<charlist inherit="1" charsubsetref="TypeInLine">
<suppress sup="1">
</charlist>
</e-i-c>

But the text is always there : I can't hide it. What am I doing
wrong ?

thanks


Highlighted

Re: FOSI

Aw, c'mon. Who wouldn't enjoy the challenge of typing blind?
Highlighted

Re: FOSI

Well with some of the TMs I've worked with in the past, I suspect that is
what was done. I recall in my younger days on the flight line questioning
the ancestry of whoever wrote the tech order I was using and wanting to do
mean nasty things to them. Then one day I got sent to Wright Pitifall Air
Farce Base and suddenly I was one of them. Been one of them for way too
many years now.

Lynn


"Benton, Ed
L" To: "adepters@arbortext.com" <adepters@arbortext.com>
<ed.l.benton cc:=" <br="/> @lmco.com> Subject: RE: FOSI
Sent by:
owner-adepter
s


09/28/2001
Highlighted

Re: FOSI

Good Day Adepters,

I have a file entity that contains "newline" processing instructions. When
I insert this file entity at different places within my document instance
and publish with our print FOSI, I find that our FOSI processes (allows)
these "newline" processing instructions to work within the file entity but
it depends on where in the document instance the file entity is used. For
example, if the file entity is used in the front matter of the document
instance, the FOSI processes the "newline" PI's but when the file entity
is used in the body, the FOSI ignores the "newline" PI's.

I know that PI's are not the best choice for achieving formatting but I'm
wondering why the FOSI treats the PI's within the file entity differently
depending on where in the document instance the file entity is used?

All help is greatly appreciated.

Thank you,
Sean
Highlighted

Re: FOSI

Does your FOSI have e-i-c's for the newline PI?

We don't, but we do look for touchup PIs:
<e-i-c gi="touchup" gitype="pi">

Maybe you've got something similar going on.
------
Paul Nagai
Highlighted

Re: FOSI

Andy is correct. You should disable the touchup menu and also use the
-nopi argument when saving. Style should always be separated from
format. Technical writers should not be messing around with new columns
or new pages or any other format-driven stuff. I wish there was a way
to get rid of the "spawn of Satan" markup (<table>) which is the only
format-driven markup that we allow in our DTDs.
Any special formatting needs should be tied to an actual "semantic"
reason (not just because somebody wants it to look that way), which
usually means using a specific tag, which also usually means a specific
e-i-c in your FOSI to apply the special formatting.
Highlighted

Re: FOSI

I couldn't agree more about the separation of content and format. I'm
stuck with these legacy documents and just hoping to understand the
difference in formatting. These "newline" PIs are not defined in the FOSI
anywhere and are inserted from Epic's Insert Markup menu when the
Mode=PIs. I believe they are controlled through the Epic software itself
and not through an e-i-c in the FOSI.

I hope my question makes sense but how does an e-i-c come into play when
you are inserting pi's right from Epic's Insert-->Markup menu? I've always
been under the assumption that the processing instructions inserted from
Epic's Insert Markup (Mode=PIs) menu are proprietary and there behavior is
directly controlled by the Epic software and not by the FOSI. If the
processing instructions was defined as an element in the DTD then I could
definitely see how the e-i-c within the FOSI would come into play.

Sorry for another question on this.

Sean

"Benton, Ed L" <->
Sent by: owner-adepters@arbortext.com
03/21/2005 12:39 PM
Please respond to
adepters@arbortext.com

To
adepters@arbortext.com
cc

Subject
Highlighted

Re: FOSI

Ed et al,

You really opened a can of worms on this one. We (Adepters) haven't had a
really good discussion thread in a long time. This one should do the
trick. 🙂

There are two approaches to developing DTDs and Schema. One is to be as
generic as possible, the other is to content tag (or have an element for
EVERY possible thing you can put in your document). The US DOD (at least
the Army and Air Force) with its propensity to be verbose tends to use
content tagging with the result there are DTDs with numerous (the Army's
40051 has 870 elements, many with the same content model. The Navy, with
their NAVSEAC2 (sick) DTD is less verbose, but this DTD is so generic that
Swiss Cheese looks solid next to it. You cannot enforce requirements with
it (emphasis on the ENFORCE).

I personally prefer a more generic approach, there is just no way in the
world that one can ever identify every possible permutation and
combination of data to develop an element that covers it. This is not to
say that I won't develop an element to meet a specific need (rather than
use a table). An example of this is a parts list. I would rather have
specific tags that I can relate to in some manner rather than have this
data just be cells in a table.

However with content tagging, I can better present my data if I have
specific elements and know that a service upon receipt comes before siting
task and neither belong in the general information. But do I need an
element for every maintenance task (i.e., remove, replace, adjust,
calibrate, etc)? No, especially when at the end of the task list, there
is that catch all element to account for what we forgot and they all have
the same content model.

A DTD is your Document Type Definition, a road map on the structure of
your document. Even the name sounds authentic, a document definition. A
Schema is the more programmatic version of the DTD for XML, it just sounds
like someone is scheming on how to deviate from the requirements. Not to
mention a schema is about four times more verbose than a DTD. So if you
are a DTD or Schema developer you really need to know your data structure
(not the format or the content, but the structure). If you have a
requirement, ENFORCE IT, don't make it part of an 'or' group because it
was easier to do. I love picking on NAVSEAC2 because they don't enforce
ANYTHING. For example here is their content model for front matter

preface | intro | contents | illuslist | tablelist | safesum)+), (fsection
| graphic)+)>

Now NORMALLY there is one title page (<idinfo>), safety summary
(<safesum>), list of effective pages (<lep> and table of contents
(<contents>), the title page comes first, the lep next, the contents and
then the safety summary. Well here is the DTD developer being either lazy
or not knowing how to enforce requirements.. One is only required to have
ONE element in the 'or' group that starts with <idinfo> and it can be any
of the list of (idinfo | lep | chgrec | foreword | preface | intro |
contents | illuslist | tablelist | safesum) IN ANY ORDER ANY NUMBER OF
TIMES. To be honest, part of this loose structure is that NAVSEAC2 has to
deal with legacy data that did not follow the standards to begin with, so
here's a model that hopefully will meet all the permutations and
combinations.

So where was I going with this (he went that away <-- -->). Oh yes, when
developing a DTD/Schema, try to keep it concise and able to meet the needs
of your author users. The more complex the DTD the more complex the style
sheet has to be to handle the formatting.

Told you you'd opened a can of worms. My old Murphy's Law calendar had a
corollary about opening a can of worms. Said that once you've opened a
can of worms, the only way to get them back in the can was to get a bigger
can.

Lynn
Highlighted

Re: FOSI

I was being a bit Draconian in my statements, but I still believe
semantic markup is better. I have also seen DTDs where they have the
same attribute on many tags, such as the attribute name "type". This
attribute can have a content of CDATA, and is implied. A <text<br/>type="whatever"> tag can have any kind of formatting you want based upon
the value of the "type" attribute. Every time you want to change the
print formatting or IETM behavior of some tag, all you have to do is
invent some new string of characters for the "type" attribute. Then
some programmer has to change the FOSI, stylesheet, IETM CSS file or
some other browser behavior to do the correct thing for this attribute
value. I don't think this is a good idea either, in most cases.
Highlighted

Re: FOSI

I couldn't really say why the PIs work in some sections of the document
and not in others, without seeing the FOSI, DTD and a document instance.
Even then, I probably would have no clue. You are correct in believing
that the touchup PIs are not normally explicitly controlled by the FOSI.
I don't know if this is your case or not, but perhaps if the entity
contents are saved in a savetext and used elsewhere in a usetext, they
behave differently or something.
Highlighted

Re: FOSI

And the choir sings "halleluiah" in support of Lynn's structure thesis.

A good reason to develop a specific set of tags instead of using the
spawn of Satan (tables) is to identify the content of the cells as Lynn
specifies in his third paragraph. There (is, was, has been for a long
time, will be someday) a requirement to link technical data into a
database that is suitable for hot retrieval. If your data is tagged
<quantity>, <partno>, <nomenclature>, <manufacturer>, then pushing it
into a data base is pretty easy. If your data is tagged <entry>,
<entry>, <entry>, <entry> then you will usually lose the option of
programmatically importing the data. Especially when an author is
allowed to change the order of the data. With a generic table there is
no way to enforce anything.

-Andy

\ / Andy Esslinger - Lockheed Martin Aeronautics Company
_____-/\-_____ (817) 777 3047 LM Aero Ft. Worth F/A-22 TOD
Integration
\_\/_/ Box 748 Mail Zone 4285 Ft. Worth, TX
76101



_____
Announcements