1-Visitor

Question

FOSI Retirement Notice

Forum|Forum|11 years ago
December 8, 2014
24 replies
6219 views

I just read about PTC's plans for FOSI retirement-see below. The news came to me on Friday in "(Updated) - 2014 Arbortext Announcements" in my daily "PTC Technical Support Subscriptions" email

The announcement below says they will continue to include the FOSI composition engine in future releases, but will no longer have any maintenance releases or patches related to it.

So, I'm wondering, Should we start migrating our FOSI style sheets to Styler or should we continue to put all our eggs in the FOSI basket since the composition engine that works for us now will be available with future Arbortext products?

2014 Arbortext Announcements

July 2015: FOSI Retirement Notice

* Beginning July 1, 2015, PTC will change the level of support for the FOSI composition engine from Standard to Sustained.

* This includes the use of XSL-FO, the FOSI Editor and the Arbortext line numbering application.

* Customers with an active Global Support agreement may continue contact PTC Technical Support as well as have continued access to technical support web tools, the knowledgebase and prior maintenance releases.

* However, there will be no additional maintenance releases or patches related to the FOSI composition engine.

* The FOSI composition engine will continue to be included in the Arbortext suite of products, and customers may continue to use existing FOSI stylesheets.

--Jack
LSI, Inc.
Jacksonville, FL

Show previous replies

ptc-953343

1-Visitor

I don't like GUIs so in my case with the lack of support in the import function, I decided to just write the Xsan directly. For me it wasn't worth the effort or the expense. We went with a standalone xsl engine and never looked back.

Sent on a Sprint Samsung Galaxy Note® II

naglists

1-Visitor

And here I was putting off thinking about the little ole' withdrawal of the
Documentum/WDK adapter .... Now this? Yay!

Not.

One of the first questions I have had is not technical. Rather it has to do
with trust. Is it worth risking the effort of converting all my FOSI
stylesheets to Styler or APP/3B2 stylesheets when PTC has shown such a lack
of commitment to non-engineering customers? I trust that if I limit my
capabilities to those required by their engineering customers, Arbortext is
probably a safe bet (at least until I retire

However, if I need
authoring and/or publishing capabilities outside of the needs of their
engineering customers, there is much greater risk.

To my technical understanding of the FOSI, APP/3B2, Architect, Styler, text
editor, [3B2 editor?], Print Composer, Publishing Engine equation and some
of the questions that arise there ...

There are two composition engines: FOSI and APP/3B2. PTC just announced
they are no longer updating the FOSI engine. We are worried about how long
it will continue to be available (if not "supported/enhanced").

Both the FOSI and APP/3B2 composition engines are available in Styler and
Publishing Engine (enterprise and developer versions ... not the names they
use, but the logic is right). The FOSI engine is available in Print
Composer ... I'm not sure whether APP/3B2 is. Someone [Gareth?] will tell
us.

FOSIs can be maintained with Architect and any text editor you love or hate.

APP/3B2 stylesheets can be maintained with _______ [Gareth again!]

Styler can be used to author stylersheets (a term PTC moved away from but
that I always liked) that are de-generalized (compiled?) on the fly to
directly feed the FOSI or APP/3B2 composition engine depending on the
request. Styler can import (some) of some stylesheets. Even if features are
not supported in Styler and stylersheets, you can code for and support them
in source edits. FOSI source edits have the same risk a standalone FOSI
does ... meaning if the FOSI engine is ever fully withdrawn, those source
edits will be unusable.

Whether converting to stylersheets, moving as much of your code into Styler
language as possible while supporting the rest as source edits, reduces
your overall risk or not is an individual exercise.

I don't fully understand how/why XSL/FO is based on FOSI but apparently it
is. I don't know whether there is some non-FOSI way to use XSL/FO but in a
less extended / enhanced / customized fashion or not.

I don't think XSL itself is threatened by the potential withdrawal of FOSI
so XSL/XSLT transformations (whether to XML or HTML) are no part of this
conversation at all. Same with export to RTF. Same with DMP.

Hopefully you all will clear up anything I have wrong and fill in anything
I have overlooked.

On Wed, Dec 10, 2014 at 10:27 AM, Dan Vint <->

ptc-5681790

1-Visitor

The original implementation of XSL, which may no longer be the case, was that you would apply your xslt to your xml to get an xsl-fo intermediate file. This xsl-fo file was then published with a FOSI for the xsl-fo doctype. So, if FOSI is at risk, XSL is at risk within any composition products that PTC deigns to sell. I've never worked with APP/3B2, so it may have some abilities that I'm not aware of.

ClayHelberg

18-Opal

You're right, Steve, and PTC did note this dependency in their original announcement.

There's no reason in principle that you couldn't make an XSL-FO renderer that runs on the APP engine, but I don't know of one that exists currently. PTC may or may not be working on such a thing. (I know at one point they were considering the possibility, but I have no idea if it's gone anywhere since then.) Theoretically, a user could even develop such a thing, if they are desperate enough to leverage an existing investment in XSL-FO stylesheets and Arbortext software-though I would think that for the cost of such an effort, it would be cheaper to just get an Antenna House server or something similar.

That is the good news for XSL-FO users: unlike FOSI, if you are publishing via XSL-FO there are a number of alternatives to Arbortext software for generating your rendered output.

--Clay

ptc-953343

1-Visitor

In today's publishing world there are only two reasons why I would undoubtedly recommend Arbortext. Those reasons being:
- need to work with SGML
- need to use FOSI

This is killing one of those reasons. When Arbortext started they were a publishing oriented company and they had one of the two SGML editors that were available. Softquad was thee other. Both companies had one focus and that was to promote the use of SGML and support general publishing.

That drive no longer exists here and the only concern is to bolt on to a larger product suite where the driver is to have integration with the design tools and process. All other uses of Arbortext are secondary. I'm surprised they support DITA as much as they do.

For the last almost 2 years I've worked at a company where Arbortext is not in the mix. Sure I miss the familiarity of the tool and some of its capabilities, but what I have gained is the old focus of a tool vendor that is focused on publishing and making XML work. That has been a welcome change. Who is the vendor? Synchro Soft and the oxygen editor. I feel loved as a tech pubs professional by this company, just like in the days of SGML.

Sent on a Sprint Samsung Galaxy Note® II

GarethOakes

16-Pearl

Hi guys,

Conversion from FOSI is going to be difficult no matter which way you turn. Each composition system has its own peculiarities and idiosyncrasies in the way it works, so be necessity any conversion will be lossy. I like the idea of a FOSI-to-XSLFO converter, there is certainly a good amount of overlap in the design of those two composition systems. FOSI-to-CompML is an intriguing thought too, for those wishing to leverage existing Arbortext licenses.

Personally, I don't believe Styler itself will be suitable replacement for most FOSI users on this list. My basis for that judgment is that Styler is only suited to basic document types and output styles e.g. Straight-up techdocs with DITA. If you have a custom doctype or "complex" styling (floats, boxing, etc.) then Styler is going to be trouble. I hope PTC comes up with a better Styler than Styler, but even if they do you can bet its features will be tailored to the manufacturing sector.

BTW, there are a number of organisations besides PTC who can assist with FOSI conversions and so on. GPSL is one of those.

// Gareth Oakes
// Chief Architect, GPSL
// www.gpsl.co

GarethOakes

16-Pearl

Hi Paul,

I can contribute a few answers, hope this helps yourself (and the group).

> Both the FOSI and APP/3B2 composition engines are available in Styler and
> Publishing Engine (enterprise and developer versions ... not the names they
> use, but the logic is right). The FOSI engine is available in Print Composer
> ... I'm not sure whether APP/3B2 is. Someone [Gareth?] will tell us.

Every Arbortext print-capable product ships with both print engines: FOSI and
APP. These engines can accept Styler stylesheets or their "native" stylesheets.

> FOSIs can be maintained with Architect and any text editor you love or hate.
>
> APP/3B2 stylesheets can be maintained with _______ [Gareth again!]

Styler can create FOSI or APP stylesheets, although the Styler GUI only
exposes/leverages a fraction of the power of each engine.

Native APP stylesheets (called templates) are usually worked on via APP
Desktop. Also most modern APP templates are Javascript so you can use
Javascript editors and so on (Sublime Text Editor, Eclipse, etc.). BTW, APP
Desktop also includes a lot of developer features such as stepwise debugger,
logging, tracing, profiling, etc.

The key point of difference here is that FOSI is a declarative language
whereas APP code is imperative. This doesn't imply one is better than the
other, but the way you work with each language is slightly different.

> I don't fully understand how/why XSL/FO is based on FOSI but apparently it
> is. I don't know whether there is some non-FOSI way to use XSL/FO but in a
> less extended / enhanced / customized fashion or not.

Only the Arbortext implementation of XSL-FO is based on FOSI. Just for
clarity, XSL-FO is a W3C recommendation (a standard). There are a number of
competing XSL-FO implementations, none of which involve FOSI.

// Gareth Oakes
// Chief Architect, GPSL
// www.gpsl.co

Anonymous

Hello all-

In reading some of the responses in this discussion thread, it is apparent there are some misconceptions which we'd like to address.

The announcement to move the FOSI engine from standard to sustained support only applies to print/PDF output, not the use of FOSI for the Edit view.
We currently have no plans to remove FOSI from Publishing Engine,Styler or Print Composer.
FOSI stylesheets will continue to work on all three platforms
FOSI source edits will continue to work in Styler stylesheets on those platforms
There are no plans to remove XSL processing from PE, it is fundamental to how PE produces other output

naglists

1-Visitor

Thanks, Gareth. I knew you would have additional information re: APP.

I should have been clearer with respect to my question about XSL/FO and
FOSI. I know that XSL/FO is a standard and supported by other
companies/technology outside of Arbortext's environment. What I am not
totally clear about is whether it is possible to use Editor and XSL/FO and
some other engine than FOSI to generate a PDF (less the Arbortext
extensions to XSL/FO). And I guess the answer is sort of ... you can author
in Editor if you wish, but to make a PDF via XSL/FO without FOSI, you would
have to use another tool to both create and respond to a "composition
request."

On Wed, Dec 10, 2014 at 5:51 PM, Gareth Oakes <->
wrote:

> Hi Paul,
>
> I can contribute a few answers, hope this helps yourself (and the group).
>
> > Both the FOSI and APP/3B2 composition engines are available in Styler
> and
> > Publishing Engine (enterprise and developer versions ... not the names
> they
> > use, but the logic is right). The FOSI engine is available in Print
> Composer
> > ... I'm not sure whether APP/3B2 is. Someone [Gareth?] will tell us.
>
> Every Arbortext print-capable product ships with both print engines:
> FOSI and
> APP. These engines can accept Styler stylesheets or their "native"
> stylesheets.
>
> > FOSIs can be maintained with Architect and any text editor you love or
> hate.
> >
> > APP/3B2 stylesheets can be maintained with _______ [Gareth again!]
>
> Styler can create FOSI or APP stylesheets, although the Styler GUI only
> exposes/leverages a fraction of the power of each engine.
>
> Native APP stylesheets (called templates) are usually worked on via APP
> Desktop. Also most modern APP templates are Javascript so you can use
> Javascript editors and so on (Sublime Text Editor, Eclipse, etc.). BTW, APP
> Desktop also includes a lot of developer features such as stepwise
> debugger,
> logging, tracing, profiling, etc.
>
> The key point of difference here is that FOSI is a declarative language
> whereas APP code is imperative. This doesn't imply one is better than the
> other, but the way you work with each language is slightly different.
>
> > I don't fully understand how/why XSL/FO is based on FOSI but
> apparently it
> > is. I don't know whether there is some non-FOSI way to use XSL/FO but in
> a
> > less extended / enhanced / customized fashion or not.
>
> Only the Arbortext implementation of XSL-FO is based on FOSI. Just for
> clarity, XSL-FO is a W3C recommendation (a standard). There are a number of
> competing XSL-FO implementations, none of which involve FOSI.
>
> // Gareth Oakes
> // Chief Architect, GPSL
> // www.gpsl.co
>

ptc-5681790

1-Visitor

The short answer is yes, quite easily. We still use editor but have recently moved pdf production from FOSI with Print Composer to XSLT/XSL-FO with Saxon + FOP. It wasn't a big leap for us because we were already producing HTML via XSLT with Saxon. It's all integrated into our overall build system and ACL customizations to launch the process.

That, of course, is one of the selling points of structured markup; being able to plug and play the best components for your particular needs and not being bound to a single software vendor.

Steve

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