Re[2]: [lmi] Calculation summary XML resources structure (with some examples)

[Vadim Zeitlin]

On Tue, 26 Sep 2006 05:24:37 +0000 Greg Chicares <address@hidden> wrote:

GC> (B) Separation of concerns: content vs. representation, or Model vs.
GC> View, for instance. The question here is: where is the separation?

 As you wrote, I believe that this is a strong argument in favour of doing
the formatting in XSLT. The model, or content, has the numbers and not the
strings and the fact that numbers are represented as strings is a detail of
the view, or representation. In fact, I could imagine without problem that
we might want to represent the numbers differently, e.g. by plotting them
(not with XSLT probably but we could still use the same XML input data).

GC> (C) Theming. The example above is oversimplified: some reports would
GC> show "5.000%" while others would need "5%" or "0.05". A single xml
GC> file could be used for all reports. This seems to favor (2), but I'm
GC> not really sure about that.

 (C) is just a particular case of (B), I think. And so it does favour the
XSLT approach because it's easier to change the formatting in XSLT than in
C++ code and it doesn't even require recompilation.

GC> (D) Speed
...
GC> (E) Scaling
...
GC> (F) Accuracy and precision
...
GC> (G) IIABDFI ( http://www.jargon.ru/slova.php?cat=227&id=712 ). We've
GC> already done (1). It is known to work.
...
GC> (H) OAOO ( http://c2.com/xp/OnceAndOnlyOnce.html ). It would seem
GC> wrong to do some numeric formatting in xslt and some in C++, and
GC> better to do it all in one or the other.

 I agree that all of the above are strong arguments in favour of doing it
in C++ code, even though (E) seems to be a subpart of (G). The most
important one is (F) because I simply can't guarantee right now that we
don't run into any of such problems (maybe Evgeniy can?).

GC> (I) Testability.

 I don't this this matters much because we need tests for XSLT stuff
anyhow, whether we do formatting in it or not.

GC> I see the arguments in favor of (1) as stronger, especially because
GC> it's already in place and has less risk. Do you strongly disagree?

 No, I don't disagree strongly. I still think it would be conceptually
better to do the formatting in XSLT and I'd prefer to do it if I were sure
to not have any problems with (F) and, to lesser extent, (D). But in the
current situation and taking into account the other points I think it's
perfectly understandable to choose to do the formatting in C++.

 We just need to understand clearly that our XML data files won't be the
primary source of the calculation data but just an intermediate step
between the C++ code generating this data and its output representation
(this could be important if we also wanted to use these XML files for data
exchange, for example). And we also will need to make sure that C++
formatting routines are as configurable and flexible as possible to
minimize the changes to this code in the future when a need for other
output formats arises. But if neither of these points is a real problem,
then, practically speaking, C++ approach does seem to be more appealing.

 Could you please definitely confirm that this is what we're going to do?
In this case we'll need to slightly modify the XML schema (to merge
double_scalar and string_scalar tags). Also, are there any other changes to
be done or should we consider these formats accepted and continue with the
next stage of the work?

 Thank you,
VZ