Known Participant

Question

Conversion Tables Again

Forum|Forum|12 years ago
December 4, 2013
4 replies
588 views

FM 11

DITA 1.2

I just got back to working on our conversion table and have two questions today:

I'm trying to wrap task topics in a task element. The headings in our source files are labeled Heading1Task, Heading1Concept, etc., so finding the tasks shouldn't be a problem for the conversion table.

My Heading1Task is set to wrap in the <title> element with a qualifier of h1task.

At the end of the conversion table I have this in the first column:

I set that to be wrapped in a <task> element.

It isn't working. I have no errors on the FrameMaker Log (Structure Document Report), the Structure View, or anywhere else.

Side question: Can I put the asterisks outside of the parentheses, like this (abstract | titlealts)* rather than after each element to indicate that everything inside is optional (zero or more)?

2. In my task topics, the steps are coming in as ordered lists. How can I tell the conversion table that it should first wrap these in <cmd> and then wrap all <cmd> elements in <step>, and finally wrap all <step> elements in <steps>?

TIA,

Marsha

Structured

This topic has been closed for replies.

L

Lynne A. Price

Inspiring

Marsha,

I suspect that the problem is indeed the placement of the asterisks. While Scott is correct that sometimes conversion table output needs to be augmented with a plug-in or script (or XSLT on an XML version of the document), it's easier to optimize the conversion table output before going to other tools.

In particular, remember that a subexpression that ends with an asterisk matches any number of things that match the expression preceding the asterisk. For example, (abstract* | titlealts*) matches any number of abstracts or any number of titlealts. It does not match a sequence containing both abstract and titlealt elements. However, (abstract | titlealts)* matches any number of items each of which matches (abstract | titlealts). Thus, when you move the asterisk outside the parentheses you are accepting sequences of any number (including 0) of the listed elements in any order.

Making the analogous change in both parenthesized groups in your expression yields

To paraphrase, this expresion matches the following in the listed order:

1. A required title qualified as h1task

2. Optionally, any number of abstract and titlealts in any order

3. A required taskbody

4. Optionally, any number of concept, ol, p, prereq, stepsection, and ul elements in any order

5. A required steps

Note that the concept, ol, p, prereq, stepson, ul, and steps elements follow the taskbody: they are not part of it.

--Lynne

M

Marsha_LofthouseAuthor

Known Participant

Thanks, Scott, for the quick reply.

I'll address the second item first. We are using the standard DITA model. (Is that what you mean?) By "these" I meant the text that is coming in as <li> elements in an <ol> rather than coming in as <cmd> elements. Currently, that text is wrapped in <li> elements, and those elements are wrapped in <ol>. I need to determine how to get that text to wrap in <cmd>. However, I don't want my <li> elements in my concepts and references to convert to <cmd>. Once I get my <cmd> elements, I can take it from there.

Regarding my first question, I didn't realize that I should only be wrapping sibling elements.

Marsha

ScottPrentice

Inspiring

It sounds like you have other rules that are getting to the"cmd" content first. When converting multiple models (supporting both task and concept content), you'll need to start off with para tags that are different so you can map the list content to <li> and the step content to <cmd>.

I know that you don't want to hear this, but my FM2DITA plugin has a command that retags paras based on other surrounding tags. For example, if you have a specific heading that identifies your tasks, you can set it up to assign a "task-" prefix to all paras that follow that heading and come before some other heading. This lets you create unique para tags for each model and makes it easier to map them in the conversion table.

If that's all you need to do you could create an ExtendScript that does this as well .. but you'll need to somehow differentiate the tags in each model. (Of course, you can manullay retag paras as well.)

Cheers,

...scott

ScottPrentice

Inspiring

Hi Marsha...

1) That wrapping rule doesn't look right to me. You should be wrapping "sibling" elements, and that list isn't that. The taskbody should already have wrapped the steps, and the last collection of grouped elements are a mix of elements that won't exist as siblings of each other or taskbody (if you're working with standard DITA).

In general, you can just take the "content model" description from the DITA Reference and use that as a template for your wrapping rules. For task you've got this ..

( (title) then (titlealts) (optional) then (abstract or shortdesc) (optional) then (prolog) (optional) then (taskbody) (optional) then (related-links) (optional) then (topic or concept or task or reference or glossentry or glossgroup) (any number) )

Yes .. put the asterisk outside of the closing paren.

2) Can't really answer this without knowing the model from which you're converting. I don't know what you mean by "these". If your steps just consist of cmd elements (no info or other bits), this should work ..

E:cmd - step

E:step+ - steps

Cheers,

...scott

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.