The better way to "x-out" macros in XPP style setups

I wanted to offer a better way to "x-out" macros in style setups.

Often when working with customer samples and composing them (or looking through the composition messages with View Log), I see lots of composition messages such as the following:

invalid xycode name (2) name = <xxmc;test;macro1;macro2>

It seems that many customers are in the habit of "x'ing out" macros in their style setups (by adding something like an "xx" prefix to the macro name) when they don't want them executed, but at the same time want them left "visible" when looking at the setup (probably in case they need to revisit the changes).

However, sometimes there are so many of these types of "error" messages that it's hard to pick out the significant composition errors. And when background queues are used to run many composition tasks, such "junk" error messages (en mass) can quickly cause queue log files to grow very large in size.

There's a better way to do this.

If you take a look at the xy_sys spec (in Lsyslib), you will see that the very first macro definition has a name of "__" (two underlines) and has an empty expansion. This definition was added years ago for use by import/export (toxsf/fromxsf) to "mark" non-XPP PI macros in the (SGML/XML) data on import so that they would be ignored by composition (and then on export the special "__ " prefix gets removed so that the data round-trips w/o any changes).

But this same mechanism can be used for macros within style setup that you want to be ignored (i.e. in xx and mx spec Expansion fields and in if spec Prestring, Poststring, and XML/SGML End fields).

So, for example, in an xx Expansion field instead of doing:

<xxmc;test;macro1;macro2>
<xxqa>

you would do:

<__;mc;test;macro1;macro2>
<__;qa>

You can also use this to do things like the following:

<__;/qa>
<mc;test;__(macro1);macro2> (as long as macro1 is not "skp" or "nul")
<mc;test;__(macro1,arg1,arg2),macro2>

The macro is still there, but by virtue of adding the "__" name it effectively gets ignored by composition (due to the empty expansion for the "__" macro) - and the bonus is that no "invalid xycode" error messages are output either. Now the composition error messages/logs are only filled with significant error messages.

Just to be clear, this suggestion is only in regards to the "style" setup within XPP; do not do this in the imported data (stream) itself.

Jonathan Dagresta
SDL XPP Engineering

Jonathan Dagresta
RWS Group/
XPP Development

  • We have a slightly different solution - instead of <xxmc;test;macro1;macro2> we use <x;mc;test;macro1;macro2> where x is in our master library macro spec with no expansion. It is then equally easy to search for and also has the same effect of not displaying in the composition log.

  • Of course few people (except me) care about composition errors.
    And SDL is not to be pleaded free from this.
    Just do a compose of the all_well division  in the Shakespeare sample jobs (both CSS and classic) and have a look at the impressive composition log. 

    So people do not care about one more (or less) error, because they were never educated to care about this.

  • We certainly care when doing initial set-up and fault finding - its an essential tool!

  • I just modified my original post as to syntax.

    After seeing Chris Leggett's reply it occurred to me that I had not written the recommended "x'd out" macro alternatives using the traditional semi-colon delimited format, but had instead used the non-traditional space delimited format.

    That happened because I was "borrowing" the use of the "__" macro from where it was originally designed to be used in the data stream for PI macros (where the syntax is tag name with space delimited attributes).

    It will actually work either way, in this case, because macro handling can key off of a space delimiter.

    But it is still more appropriate (or traditional) to do:

    <__;mc;test;macro1;macro2>
    <__;qa>

    instead of:

    <__ mc;test;macro1;macro2>
    <__ qa>

    Jonathan Dagresta
    SDL XPP Engineering

    Jonathan Dagresta
    RWS Group/
    XPP Development

  • I appreciate Chris mentioning an alternative; users are certainly free to define their own "ignore" macro.

    Just keep in mind that one advantage of using the "__" macro is that it is already defined in the standard XPP setup (in the xy_sys spec) and so, if you use "__" you do not have to worry about any potential future naming conflict with standard macro definitions that might get added to XPP. And it's just as easy to search for as well.

    Of course, XPP developers are not likely to add a standard macro named just "x" (or even "xx").  Wink

    Jonathan Dagresta
    SDL XPP Engineering

    Jonathan Dagresta
    RWS Group/
    XPP Development

  • "So people do not care about one more (or less) error, because they were never educated to care about this."

    I agree that people were never educated to care about this. The education starts here!  Nerd

    After all, isn't this one of the big reasons for this forum (and for the XyUser Group forum, now incorporated here) - to share not just questions or requests for help, but also best practices?

    Yes, short term people only want to get work done, but long term being sloppy in this regard is going to probably bite you - one way or another.

    I've seen customer samples where 75% of the composition error messages were of this x'd-out-macro type. I've seen customer macro definitions which included 40 x'd out macros (and so composition of just that one macro would cause 40 composition error messages). And so on.

    I'm not expecting that everyone will go through and "rewrite" all their setups; it's just something to keep in mind going forward (for those still using classic macros).

    "And SDL is not to be pleaded free from this.
    Just do a compose of the all_well division in the Shakespeare sample jobs (both CSS and classic) and have a look at the impressive composition log."

    Also true, although I'm not sure why you think the all_well Shakespeare sample jobs fall into this category I'm discussing, since I just composed them and there's not a single occurrence of an error message with an x'd out macro.  Thinking  There will always be some composition messages (and a lot of them too, if there are a lot of pages).

    Personally, I've never written any XPP style stuff - it's just not part of my job. But I do see a lot of it.  Slight smile

    Jonathan Dagresta
    SDL XPP Engineering

    Jonathan Dagresta
    RWS Group/
    XPP Development

  • Jonathan,

    Yes let the education on the rules for a good xpp style setup start here....

    I fully agree with your statement: 
    "Yes, short term people only want to get work done, but long term being sloppy in this regard is going to probably bite you - one way or another"
    Believe me in my over 30 years of experience of helping people with their xpp system, I have seen more than my share of sloppy setups turning into a maintenance nightmare.

    But I have to disagree with you when you say: "there will always be some composition errors and a lot of them if there are a lot of pages". And I certainly disagree when it is a job as simple as the Shakespeare job.
    With a little more love and care it is perfectly possible to set up your styles so that there are NO composition errors (unless there is a real error or exceptional situation). 

    Composition and pagination errors should only be generated when a page or line falls out of spec. If you get a lot of pagination or composition errors, you have set up your rules too tight and you should relax your rules and give the system more flexibility in resolving problem situations.

    When you do an initial test setup and you get a lot of errors, you need to put the extra effort in your style setup to tune these down to an absolute minimum. The big reason for this is that otherwise the errors become meaningless as they are not 'errors'. This will create the unfortunate situation that the operator will simply ignore the composition log because it is full of 'errors' which are perfectly fine. Like that there is a big chance that real errors get overlooked. 

    The base rule for a good setup is very simple: an error should only be generated when there is a true error condition.

    And I will repeat again what I said: the Shakespeare job is a bad example of a good xpp setup. It could and should be done a lot better. 

  • Maybe we need to start a new discussion item:
    "Why you should always aim for 0 composition or pagination errors when you are setting up styles in XPP"
    GrinningGrinning