1-Visitor

Question

FOSI approach vs XSLT

Forum|Forum|15 years ago
May 20, 2010
21 replies
3504 views

I've been doing lots of work in XSLT/FO but I'm having to switch gears and
work on a FOSI.

I'm in the XSLT/XPATH mindset and I know there are similar capabilities,
but I'm wondering if the approaches to problems would be different. The
I'm currently considering is transformation, specifically moving large
sections around. So I have a rear section that can contain appendices,
list of effective pages, index, etc. In my DTD I want to set a specific
order and repeatability on these objects. So I have the following:

* appendix
? index
? lep

well some groups might want the lep in front of the index. With XSLT I
would just choose to process the lep before the index and I wouldn't
change the physical order in the content. FOSIs I've seen in the past seem
to just process things in place in terms of large objects. They generate
text and such but I don't think I've seen much reorganization of the
content.

Is this a limitation of FOSIs or just the [programming style of the writer?

..dan

Show previous replies

B

bibach

1-Visitor

On Thu, May 20, 2010 at 7:37 PM, Paul Nagai <-> wrote:
>
>> The key to success with FOSI is to think in terms of context and
>> occurrence. Procedural thinking usually does not apply.
>
> I sense a PTC/User 2011 Panel: FOSI vs. XSL(/FO). Come up with some prepared
> "problems" and show the strength and weaknesses of each technology and then
> take problems from the audience

Hey, Paul...

There might be more to that winking smiley than first appears, but
just in case, have you checked out the Arbortext agenda for PTC/User
2010?

> Extra points if we can come up with a session title including the word
> "Shoot-Out"!

Actually, we had to settle for "Shootout" when our other panelist
couldn't figure out how to work in "Thundah Down Undah".

-Brandon

N

naglists

1-Visitor

LOL! There are a couple of touch-points on that thing. That agenda must have
snuck into my subconscious.

On Thu, May 20, 2010 at 4:53 PM, Brandon Ibach <
brandon.ibach@single-sourcing.com> wrote:

>

E

ebenton

1-Visitor

I haven't had nearly as much practice with this stuff as Suzanne, so maybe I'm wrong; but I always thought that XSL/XSLT was pretty fast, but adding the "-FO" to the end of "XSL" was what slowed thing down significantly. Like I said, maybe I'm wrong

A

Anonymous

I was going to suggest pseudo-attributes as well. I try to avoid them
if I can (they require you to put a special PI into your XML DTD and
compile them like SGML DTDs), but they do serve a useful purpose.

Another suggestion (and a method I use to generate most LEP and TOC
content) is using the userule of a usetext to write out aggregated
content to external files. Then you can use ACL/Perl/XSLT to tape
documents back together in any order you want. A nice feature is this
provides you the ability to read in SGML documents and create XML output
from them (which if you have a lot of inclusions/exclusions and other
SGML-only constructs can come in really handy).

For allowing authors to drive some of the content/formatting decisions
without letting them near the stylesheets, using ACL with system-func
attribute rules are pretty useful. Just use them sparingly. I've seen,
under certain conditions, these cause the system-crippling effect that
Paul has mentioned before.

-Jason

C

ClayHelberg

18-Opal

Hi Ed-

You're at least partially right. The XSL transformation itself can be
very fast or very slow, depending on how involved the transformation is
and how well you've coded your stylesheet. There are many ways to code
an XSLT stylesheet badly, so I think this has given it a somewhat
exaggerated reputation for slowness. In many cases, when an XSL
transformation is slow, it's not because of the process per se, but
rather because the stylesheet author inadvertently chose an inefficient
method to accomplish their goal. I once worked on a stylesheet that was
taking about an hour to process a document; with a few simple XPath
changes, I was able to make it do the same job in a few minutes.

As for adding the -FO, that does add some extra layers to the publishing
process, especially with Arbortext. In Arbortext, XSL-FO publishing goes
something like this:

1) The source XML is transformed to XSL-FO markup via XSLT
stylesheet

2) Arbortext does some post-processing to propagate inherited
properties and other "cleanup" tasks it needs for the next step

3) The XSL-FO instance is published using a special FOSI stylesheet
designed for the XSL-FO doctype

So, you can see, XSL-FO publishing will generally take at least as long
as standard FOSI publishing because of step 3, plus whatever time is
required for steps 1 & 2. Step 1 can be demanding, because the
transformation to XSL-FO has to transform pretty much every element in
the document into something else in the XSL-FO vocabulary. Even so, with
careful coding it can be made reasonably efficient.

Whether or not the time difference between XSL-FO and FOSI is
significant or prohibitive will depend on the specific situation, i.e.
how large the documents are, how complex the transformations are, and
how efficient the XSLT stylesheet is.

--Clay

P

ptc-953343

Author

1-Visitor

> I haven't had nearly as much practice with this stuff as Suzanne, so maybe
> I'm wrong; but I always thought that XSL/XSLT was pretty fast, but adding
> the "-FO" to the end of "XSL" was what slowed thing down significantly.
> Like I said, maybe I'm wrong

Is that in an Arbortext environment only?

Based upon Clay's statements and some of Suzanne's it looks like they run
FO out to FOSI before doing any work. I've only used this stuff outside
Arbortext with products like Apache FO, RenderX and Antenna House and have
not had any serious problems. Now I wasn't running massive jobs or large
volumes on a daily basis so it wasn't a problem I needed to find a
solution for. If you already have the Print Composer maybe FOSI is the
most efficient way to go, but it is expensive both as a product and the
fact that there aren't many who know the language and in some cases don't
want to learn it. So your cost is not just in the runtime environment.

It is a different world where XSLT/FO are being taught and used in school,
so now you have trained bodies available. Also you can get a free soultion
in Apache and not too expensive in RenderX/Antenna House.

I have to deal with FOSIs primarily becasue I'm doing defense work and
that is the standard. But even there I was doing some NAVSEA work and they
have switched over to Contenta and their proprietary formatting language.

From an Arbortext standpoint it doesn't bode well when Styler is not able
to ingest a working FOSI and let people switch back and forth easily. So
if you have one or more legacy FOSIs around you can't even get them into a
tool that novice users might be willing to use. FOSIs are just this weird
animal that we have to deal with.

..dan

>

P

ptc-1908075

1-Visitor

Efficiency is one of the problems I see with XSL and, for that matter, DSSSL. Of the many ways to code an XSL or DSSSL stylesheet that produces the desired output, most will not be optimal. Coming from a production background, that spells trouble to me, especially since I know from my consulting experience that not every developer is a careful coder.

There are also many ways to code a FOSI. You can use charsubsets and/or environments and/or direct coding -- but that affects only(!) ease of development and maintenance, not run-time, because FOSi is compiled. Optimization is a product issue, not an issue for the FOSI developer. It is true that too many attribute rules and/or system-funcs can cripple FOSI performance, but that's about it. Otherwise, FOSI runs as fast as the content permits.

L

lfraley

1-Visitor

Sounds like the makings of a drinking game for a late night at PTC/User!

And definitely a topic for discussion at the TC.

On Fri, May 21, 2010 at 9:55 AM, Suzanne Napoleon <
SuzanneNapoleon@fosiexpert.com> wrote:

> Efficiency is one of the problems I see with XSL and, for that matter,
> DSSSL. Of the many ways to code an XSL or DSSSL stylesheet that produces the
> desired output, most will not be optimal. Coming from a production
> background, that spells trouble to me, especially since I know from my
> consulting experience that not every developer is a careful coder.
>
> There are also many ways to code a FOSI. You can use charsubsets and/or
> environments and/or direct coding -- but that affects only(!) ease of
> development and maintenance, not run-time, because FOSi is compiled.
> Optimization is a product issue, not an issue for the FOSI developer. It is
> true that too many attribute rules and/or system-funcs can cripple FOSI
> performance, but that's about it. Otherwise, FOSI runs as fast as the
> content permits.
>

P

ptc-1908075

1-Visitor

I agree FOSI is a weird animal. (makes me wonder what animal O'Reilly would pick for a book on FOSI) FOSI is a declarative language that describes the problem and leaves the solution to the interpreting software. This is naturally disruptive to anyone accustomed to procedural and functional languages. The trick is to stop thinking about telling the software what to do. Instead, tell it what it wants to know where it wants to know it. The software does the rest. Hmmm . . . maybe the analogy is moving from the pilot's seat to the navigator's seat . . .

C

ClayHelberg

18-Opal

Hi Suzanne-

Interesting. I have to admit, when you say "the developer doesn't have
to be a computer scientist to be able to develop an easy-to-maintain
FOSI", it makes me think of the brilliant math professor who presents a
subtle and complex proof and claims "It's intuitively obvious!" To the
professor, it probably is; to the students, not so much.... 🙂

I wonder if FOSI seems easy to you simply because you have such enormous
depth of knowledge and experience with it. I can't speak for anyone
else, but I myself don't find anything about FOSI stylesheets to be
especially easy. This is exacerbated by the fact that information about
FOSI is so hard to come by-which is why we're all so eager for your book
to be done.

There is probably something to the argument that FOSI lets you get the
most out of Arbortext. OTOH, to develop the level of skill necessary to
do some of the things you mention as examples, I think you would have to
spend a good bit of time specializing in FOSI development. In that
sense, you would be just about as specialized as the average "computer
scientist", albeit in a different kind of technology.

--Clay

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