include profiling in generated tables in FOSI?

[naglists]

I would like a generated table's footer to contain profiling. Specifically:
<tfoot revision="Version_2;Version_3">

So this footer would only appear in, yeah, version 2 and version 3. It would
be suppressed in version 1.

It's not working, however. The profiling step of the content processing
pipeline precedes the FOSI / formatting step.

I remember now thinking it would be a good feature (I'll go submit it, I
think I've only talked about it) to have access to profiling in the FOSI.
Something like:

<specval attname="revision" attloc="#FOSI" attval="Version_2">

I've always "solved" these problems before by supporting an element
(<version_2> and <version_3) here,=" for=" example)=" that=" would=" be=" appropriately<br="/>profiled by the author and presence testable by the FOSI.

Anyone solved such things another, more elegant way?

--
Paul Nagai

[ptc-1908075]

Paul,

I'm not sure I understand exactly what you want to do. Am I on the right track with the code below?The specval in tfoot might need to use a system-func ...

<e-i-c gi="tfoot" context="*" table&quot;=">
<charlist inherit="1">...</charlist>
<att>
<specval attname="revision" attloc="tfoot" attval="version_1">
<charsubset charsubsetref="SUPPRESS"></charsubset>
</att>
</e-i-c>

<e-i-c gi="whatever">
<charlist inherit="1">
<usetext source="!&lt;table&gt;&lt;tgroup cols="1"&gt;&lt;br /&gt;&lt;thead&gt;&lt;row&gt;&lt;entry&gt;!,thhead.txt,!&lt;/entry&gt;&lt;/row&gt;&lt;/thead&gt;&lt;br /&gt;&lt;tfoot revision="version_2;version_3"&gt;&lt;row&gt;&lt;entry&gt;!,tfoot.txt,!&lt;/entry&gt;&lt;/row&gt;&lt;/tfoot&gt;&lt;br /&gt;&lt;tbody&gt;&lt;row&gt;&lt;entry&gt;!,tbody.txt,!&lt;/entry&gt;&lt;/row&gt;&lt;/tbody&gt;&lt;br /&gt;&lt;/tgroup&gt;&lt;/table&gt;!"></usetext>
</charlist>
</e-i-c>

Suzanne
"WYSIWYG is last-century technology!"
www.FOSIexpert.com

[naglists]

Hi Suzanne,
It was great meeting you at PTC/User 2009. I hope you can make it again next
year.

Yes, you're on the right path. I don't know how to write a system-func (or
any ACL for that matter) that can tell what profiling has been submitted
with a composition request. That's the feature request I wrote up, asking
for some method of testing the composition profiling values submitted.

As far as I know, there is no way to do this now.

I have a solution that works if you have control of the DTD. Simply allow an
EMPTY element at the beginning of any element's content model that might
appear as a top level element in a chunk. Authors then include that element
and profile it accordingly. FOSI defaults a text variable to NO and sets it
to YES when/if that element is found. Then your specval tests that text
variable.

Workable if you have time and, as I said before, control over the DTD. Maybe
it could also be done with namespacing. Haven't pursued that at all.

The best solution to my thinking, though, is programmatic access to those
composition-time profiling values.


On Sun, Aug 16, 2009 at 4:52 PM, Suzanne Napoleon <
SuzanneNapoleon@fosiexpert.com> wrote:

> Paul,
>
> I'm not sure I understand exactly what you want to do. Am I on the right
> track with the code below? The specval in tfoot might need to use a
> system-func ...
>
> <e-i-c gi="tfoot" context="*" table&quot;=">
> <charlist inherit="1">...</charlist>
> <att>
> <specval attname="revision" attloc="tfoot" attval="version_1">
> <charsubset charsubsetref="SUPPRESS"></charsubset>
> </att>
> </e-i-c>
>
> <e-i-c gi="whatever">
> <charlist inherit="1">
> <usetext source="!&lt;table&gt;&lt;tgroup cols="1"&gt;&lt;br /&gt;&gt; &lt;thead&gt;&lt;row&gt;&lt;entry&gt;!,thhead.txt,!&lt;/entry&gt;&lt;/row&gt;&lt;/thead&gt;&lt;br /&gt;&gt; &lt;tfoot&lt;br /&gt;&gt; revision="version_2;version_3"&gt;&lt;row&gt;&lt;entry&gt;!,tfoot.txt,!&lt;/entry&gt;&lt;/row&gt;&lt;/tfoot&gt;&lt;br /&gt;&gt; &lt;tbody&gt;&lt;row&gt;&lt;entry&gt;!,tbody.txt,!&lt;/entry&gt;&lt;/row&gt;&lt;/tbody&gt;&lt;br /&gt;&gt; &lt;/tgroup&gt;&lt;/table&gt;!"></usetext>
> </charlist>
> </e-i-c>
>
> Suzanne
> "WYSIWYG is last-century technology!"
> www.FOSIexpert.com

[ebenton]

Namespacing works with schemas. Not so much with DTDs.

[ebenton]

I take that back. It works OK with DTDs in Arbortext. With 3rd party
parsers, namespaces and DTDs don't usually play well together.

[ptc-1908075]

Paul,

It was great to meet you, too 🙂 Hopefully I'llmake it to PTC/User next year.

Re: your profiling situation, all I can say is what I always say:"Good Luck!"

😉
Suzanne

[ClayHelberg]

Hi Paul-



Have you examined the params[] array that is passed to the composer?
That should contain an entry with the profiling specs. Look for an entry
with the key 'profiles'. It will probably be some markup that you'll
have to parse, but hopefully you can get what you need from that.



--Clay

[naglists]

Thanks for the idea, Clay. I'll look into that. I think Brandon suggested
the same or at least similar avenue (I haven't had a chance to pursue it)
offline. It would be much nicer to solve this via ACL rather than
elements/DTD mods, on the other hand, the DTD mods work. Now. Already. Maybe
when I get some down time at the start of our fiscal year. Anyhow, when I
figure out how to make one of these work (or get stuck trying), I'll let you
all know.