7. Implemented weights (aka costs)
Adding the OOConverter caused quite a lot of new conversions to appear on the list and also quite a lot of ways of how to get from input to output. Therefore the user interface was starting to get again a bit chaotic and with adding more and more conversions, the current way of calculating all possible paths was taking too long. Therefore, I needed to add some mechanism to decide which conversion paths should be used and which shouldn't. After some discussions, I have decided to assign a cost to each conversion. These costs are very subjective and simply represent how good did I think the conversions were. By good I mean mostly how close to the original the resulting document was. The lower the cost, the better the conversion seemed to me. To accommodate of this cost mechanism I had to change several parts of API and framework and also each of the converters.
Up: Contents Previous: 6. Added OOConverter Next: 8. Automatic detection of new extensions for XslConverter