I remember that problem with the pageset style panel mangling the markup. I don't recall it happening recently in 5.3, but maybe like you I learned to avoid the problem by using the tagged editor. I'll have to check ...
<plug>My FOSI tutorials explore the strengths of the two FOSI interfaces because they are best used together. For example, show ids in the tagged editor, Resolve in the style panels.</plug>
Epic6: What controls the "completeness check," and how can I override it?
The additional checks, such as those involving the format of xrefs, are based on requirements in the DITA specification, as Dan suggested. These are what constitute the "enhanced completeness check" provided by the Arbortext DITA application. You can read about this by typing "help 14960" at the Editor command line.
Running the "alias" command I mentioned will bypass the enhanced completeness check and just run the normal one, which only checks the document for validity against the DTD or schema.
On Thu, Aug 11, 2011 at 1:39 PM, Garen Torikian <email@example.com> wrote: > > > In Reply to Brandon Ibach: > > But how does Arbortext decide what counts as "completeness"? If the type > attribute on an xref, for instance, accepts CDATA, it shouldn't matter if I > put new-window:PDF or kalamazoo or what-have-you. How come the check flags > it as a warning? > > All of the checks of DITA constraints beyond what is enforced by the > DTD are part of the "enhanced completeness check" provided by the > Arbortext DITA application. If you just want the regular completeness > check, you could redefine the command alias invoked by the "Check > Completeness" menu and toolbar button: > > alias CheckCompleteness cc -full > > -Brandon 🙂 > > > On Wed, Aug 10, 2011 at 6:08 PM, Garen Torikian > <firstname.lastname@example.org> wrote: >> We're starting to create Schematron files to validate our XML content, now >> that support for them has been introduced in Arbortext Editor 6. >> >> However, when writers on the team use the "Check Completeness" feature, >> they >> receive a list of warnings that are completely safe, in addition to >> legitimate Schematron issues. For example: >> >> DITA Markup ProblemsWARNING: >> >> "foo.xml" is missing an xml:lang attribute on the root element. >> >> DITA Reference ProblemsWARNING: >> >> Unusual value "new-window:PDF" specified for type attribute on xref >> element >> in "foo.xml". >> >> WARNING: External/Peer reference to "bar.pdf" on xref element in "foo.xml" >> is not represented in a correct format >> >> >> >> While Arbortext may think that every root element, for example, needs an >> xml:lang attribute defined, we put ours in during build time in order to >> support multiple languages. And new-window:PDF is also an attribute used >> for >> special purposes for the build. >> >> Is there some way I can override or "block" checks that I know are not >> necessary? At the least I'm looking for just running Schematron against >> the >> file, but what would be best is Schematron + well-formedness / context >> rules. >> >
I guess I'm spoiled by being where I am, but we DO have Architect, and I wouldn't want to do FOSI without it. Hate the panels myself, for the most part. Only use them to be certain which <e-i-c> is being applied to a given element in a specific context.
Otherwise, all my changes/analysis/whatever is done in the FOSI Editor. Keeps the structure clean and allows doing a number of things that I've not seen or heard were possible in the panels. A text editor on its own (yes, I've used one rarely) would drive me nuts with double-checking that I hadn't broken anything. And with the FOSI Editor, you can do the same "Apply" without saving until you're satisfied on at least an interim basis.
Long-winded way of saying: really glad we have Architect, and I believe it would be worth the price for you, if it's at all possible.
$.02, Steve Thompson +1(316)977-0515 -----End Original Message-----