1-Visitor

Question

FOSI approach vs XSLT

Forum|Forum|15 years ago
May 20, 2010
21 replies
3492 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

ebenton

1-Visitor

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

1-Visitor

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

Author

1-Visitor

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

1-Visitor

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

1-Visitor

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

Author

1-Visitor

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

1-Visitor

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

Author

1-Visitor

> 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 faster/better whatever.

- I see that Arbortext has extended the FOSI standard - saw reference to
being able to use XPATH systex. I didn't find any real examples of using
that. This is one of those areas of switching from XSLT/XPATH to EIC is
awkward - or at least I've not totally gotten back into the EIC
methodology but if I could use XPATH might help.

I have no option I have to do this task in FOSI it is just the changing
gears that I'm having troubles with.

thanks
..dan

>
> Good luck!
> Suzanne Napoleon
> www.FOSIexpert.com
> "WYSIWYG is last-century technology!"
>
>
>

ptc-1908075

1-Visitor

See blue below.

naglists

1-Visitor

> 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

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