FOSI approach vs XSLT

[ptc-953343]

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

[ebenton]

Reordering of content with FOSI is usually done by suppressing the content at its original location, saving it as a variable, and then outputting the variable someplace else. In some cases this might involve forward-referencing of the variable.

I personally think you would be better off using XSLT to re-order the content and then applying FOSI to the result.

[naglists]

I am not suggesting that these would be more efficient than the methods you
and Ed have already discussed, just identifying other possibilities ...

You could manage the different document order in the XML. One way to do that
would require control of the DTD and implementing profiling.

(index | lep)*

And your XML looks like this:

</appendix>
<index group="A"/>
<lep/>
<index group="B"/>

When the differences get really complicated, two or more assemblies
referencing the same information may be easier. We have a couple of such
cases where two versions of a document share 90% of their chapters but the
order of some chapters is different. We're also re-using content and
profiling where necessary to begin with, but we do solve the problem you
mention that way, too.

[ptc-953343]

Haven't worked much with profiling.

One thing I was trying to avoid in the DTD was having index or lep repeat.
Typically I see people punt on this and just have everything in a
repeating choice group. Which handles this and lets the author place it
where ever they want and the FOSI just formats it in location.

I guess I relate better to "transformation" instead of hiding and reusing.
I am more current in XSLT and that influences the way I think about the
problem. It also influesnce the termenology and how you search a spec for
"can you do this ...".

..dan

> I am not suggesting that these would be more efficient than the methods
> you
> and Ed have already discussed, just identifying other possibilities ...
>
> You could manage the different document order in the XML. One way to do
> that
> would require control of the DTD and implementing profiling.
>
> (index | lep)*
>
> And your XML looks like this:
>
> </appendix>
> <index group="A"/>
> <lep/>
> <index group="B"/>
>
> When the differences get really complicated, two or more assemblies
> referencing the same information may be easier. We have a couple of such
> cases where two versions of a document share 90% of their chapters but the
> order of some chapters is different. We're also re-using content and
> profiling where necessary to begin with, but we do solve the problem you
> mention that way, too.
>
> On Thu, May 20, 2010 at 10:03 AM, Benton, Ed L <->
> wrote:
>
>> Reordering of content with FOSI is usually done by suppressing the
>> content
>> at its original location, saving it as a variable, and then outputting
>> the
>> variable someplace else. In some cases this might involve
>> forward-referencing of the variable.
>>
>> I personally think you would be better off using XSLT to re-order the
>> content and then applying FOSI to the result.
>>
>>
>

[naglists]

No doubt there are issues regarding loosening a DTD.

Depending on the size of various problems and limitations surrounding the
one you're trying to solve, though, sometimes doing the wrong-but-easy thing
is the shortest path to the Next Problem 😉

FOSI is inflexible (truly event driven ... you say tomato, I say ...) with
regard to its document node processing order. You can "trick" it through a
variety of methods, however. Suppressing,storing, and expressing content
later (or earlier but on a subsequent processing pass) are first among those
tricks, I'd say.

[steve.thompson4]

For what it's worth...

I'm considered the resident XSLT guru, here, and do a great deal of FOSI work, as well. Doesn't make me know-all about either. Nevertheless...

In my mind, as with Dan, XSLT is primarily about transformations, even though both can be referred to as stylesheets. FOSI is primarily about formatting. And that's where the rub comes in.

Loosening the DTD shouldn't be necessary, but it will require acceptance of the fact that FOSI is about formatting, and will therefore require a less direct approach to reordering content. That said, it is actually very good at doing so, and can handle relatively large chunks of content in that process. Suppressing, saving, and displaying on a subsequent pass may sound convoluted to an XSLT-centric mindset, but it works quite well most of the time.

I encourage Dan to go down that route, if formatting is the primary thing needed from the process. More elegant in the long run than possibly loosening the DTD, etc. And the 'etc.' has a way of proliferating, once you start down that path.

Longer than two cents worth, but then, there you have it. I'm verbose. 🙂
Steve Thompson
+1(316)977-0515

[ptc-953343]

My question had two purposes:

1) Figure out if it could be done
2) Help me get into the FOSI mindset

I haven't touched FOSI work in some time and when taught it was based upon
the CALS DTD and the thought at the time of the late 90's. Now jump
forward 15 yrs and the experience with XML/XSLT it is a little jarring to
change the processing model in my head. I've been easing into this over
the last couple of months.

I've not used XSLT/FO within the Epic environment, I've alwasy done that
at the command line with no problem. This application will have to work
within Epic and be runable by all the authors - not just me. It may be
worth it to just figure out how to hook in an XSLT preprocessing step and
build a pipe line.

Thanks for the guidance.

..dan

> For what it's worth...
>
> I'm considered the resident XSLT guru, here, and do a great deal of FOSI
> work, as well. Doesn't make me know-all about either. Nevertheless...
>
> In my mind, as with Dan, XSLT is primarily about transformations, even
> though both can be referred to as stylesheets. FOSI is primarily about
> formatting. And that's where the rub comes in.
>
> Loosening the DTD shouldn't be necessary, but it will require acceptance
> of the fact that FOSI is about formatting, and will therefore require a
> less direct approach to reordering content. That said, it is actually very
> good at doing so, and can handle relatively large chunks of content in
> that process. Suppressing, saving, and displaying on a subsequent pass may
> sound convoluted to an XSLT-centric mindset, but it works quite well most
> of the time.
>
> I encourage Dan to go down that route, if formatting is the primary thing
> needed from the process. More elegant in the long run than possibly
> loosening the DTD, etc. And the 'etc.' has a way of proliferating, once
> you start down that path.
>
> Longer than two cents worth, but then, there you have it. I'm verbose. 🙂
> Steve Thompson
> +1(316)977-0515

[ptc-1908075]

Dan,

How long are the documents? What kind of processing/formatting speed is expected? FOSI is fast, XSL is not. Note that Arbortext Editor has a formatting pass reduction feature that can make a big difference with long documents. I know it works with FOSI. I don't think it works with XSL-FO.

Also, index and lep are typically singleton tags that generate their output -- there is no need to suppress anything. And you can generated the index and lep from any start, end, or singleton tag that is in the right place (index and lep tags can be left uncoded). For example, the e-i-c for appendix occurrence=last could output the index from a usetext with placemnt=after.

<advertisement role="commercial">I suggest you check out my FOSI Quickstart Tutorials (

[ptc-953343]

> Dan,
>
> How long are the documents? What kind of processing/formatting speed is
> expected? FOSI is fast, XSL is not. Note that Arbortext Editor has a
> formatting pass reduction feature that can make a big difference with long
> documents. I know it works with FOSI. I don't think it works with XSL-FO.

My question wasn't so much about system performance as it was my
performance in finding the right answer. They are different models to
achieve similar results.

>
> Also, index and lep are typically singleton tags that generate their
> output -- there is no need to suppress anything. And you can generated the
> index and lep from any start, end, or singleton tag that is in the right
> place (index and lep tags can be left uncoded). For example, the e-i-c for
> appendix occurrence=last could output the index from a usetext with
> placemnt=after.

That assumes that you always want one to be produced, but yes that would
probably work as well. They seem to want the ability to create their own
title, so that tends to take from teh singleton model. What I haven't
thought through is how to toggle different locations. I seem to have a
milspec that says one thing, but the reality of my samples is there is
some variation in location. I've not determined if this was a critical
design decision or someone messed up.


>
> <advertisement role="commercial">I suggest you check out my FOSI
> Quickstart Tutorials (
clean code samples that show all the related things that have to be
change. I relate to (and use that document) more often. I guard it with my
life and wish it was included in the Epic docset

- in todays world, it might be useful to have an "in XSLT you would do
this, in FOSI you do this" and it is much...

[ptc-1908075]

See blue below.

[naglists]

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

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

--
Paul Nagai

[bibach]

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

[naglists]

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:

>

[ebenton]

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

[JasonBuss]

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

[ClayHelberg]

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

[ptc-953343]

> 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

>

[ptc-1908075]

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.

[lfraley]

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

[ptc-1908075]

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

[ClayHelberg]

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

[ptc-1908075]

I should confess I have a grudge against XSL because it did not become what it was supposed to be. XML was supposed to be "SGML for the Web," and XSL was supposed to format it. Specifically, browsers were supposed to display native XML formatted with XSL. The idea, as Soft Quad founder Yuri Rubinsky put it, was to change the Web from a giant brochure into a giant database.


Instead, XSL became a way to transform XML into HTML for display in a browser, which led to XSLT as a general transformation engine like the first stage in DSSSL. XSL-FO was tacked on at the end pretty much as an after thought. And browsers continued to be HTML-based.

Frankly, I still want that giant XML-based database. Of course, XSL couldn't be used to format an XML-based web because the transformation phase makes it too slow, which is why Arbortext doesn't use it for the Edit window display.

A few comments are embedded below.


----------