RE: ACTION-54: Try to come up with example of xliff+its test format / output

> If you use the counters having such output (of course 
> independent of the testing task) will be easy to achieve.

With counters sounds fine... (and it may be easier to get when working with XSLT)
Attached an updated input and output.

And here is a summary of the format:

- Only the structural elements that may have ITS-related data are listed (xliff, file, group, unit)

- The text nodes are also listed (because in case of overlapping the elements nodes are not enough information). They are
represented by an offset "#start,end" the values are zero-based and start at the beginning of the content (source or target). Inline
tags have no length, whitespaces are normalized (without trimming trailings or endings).

- Inline markers (mrk, sm, em) are represented by the text "{<type>:<fragId>}" where <type> is "START" or "END" depending of the tag
type, and <fragId> is the absolute fragment identifier for the given marker.

- Inline codes (ph, pc, sc, ec) cannot have ITS-related data, so they are not represented in the output.

- The data elements are not represented (the only ITS-related data possible there is the Preserve Space and it is forced to
'preserve'.

I've updated Lynx to generate such output and it's available here:
http://okapi.opentag.com/snapshots/okapi-xliffLib_all-platforms_1.1-SNAPSHOT.zip

Cheers,
-ys