Optimal way of making Xembler work with Report is not obvious

[gsnoff]

As per #227:

Refactor towards a simpler solution that ideally would just require one or two Xembly instructions add the required attribute.

The problem with using Xembly here is summed up by the following (see #196 (comment)):

Xembler works with nodes. Can't set the required attribute on the node returned by the XML resulting from transforming the skeleton into metric because it's a document node (throws error "Cannot cast ...DocumentImpl to ...Element").

Because it is not obvious what would a better solution look like exactly, I think this separate issue is needed so that the scope of #227 itself wouldn’t go beyond 30 minutes. We probably need to make a design decision here first.

[0crat]

@paulodamaso/z please, pay attention to this issue

[gsnoff]

/cc @yegor256 @llorllale

[gsnoff]

@yegor256 @paulodamaso @llorllale Apparently there is a possible (relatively) clean solution. What was really needed here is to point the cursor to the metric element via an XPATH instruction first.

See #325 #326

[llorllale]

@Protagores I see that you've successfully managed to add the attribute with Xembly; what I don't understand is how this is any less "weird" (as per Yegor) than simply making use of the existing XSLChain.

I'll let @yegor256 decide.

[gsnoff]

@paulodamaso Proposed solution already accepted and merged. Closing this.

[0crat]

Job gh:yegor256/jpeek#322 is not assigned, can't get performer

[0crat]

This job is not in scope