Hi Sergey,
Many thanks for an interim release with some logging and exception description. I'm looking forward to testing this.
I also wanted to clarify the following:
'Ignore XML elements with no values.'
I would have described this approach slightly differently ...
'Provide default values when optional XML Elements are missing'.
(or unhandled elements / attributes are found (not implemented yet) - like Stubs).
(required elements, unhandled elements (those you don't have a processor for) or elements you need to make the interface work should be flagged and optionally allow my application to provide a default value) and if necessary save the XML to pass through to the output.
NOTE: For new projects, I have dealt with this problem by using a 'new' template. This has the minimum tags and defaults I need ... and the user can tailor this to their own needs.
I'm now reading a lot of XML generated by different tools and am generating output for a number of different tools (e.g. many of the MS Project Readers. There are some MS Project Readers that cannot read the XML from Aspose.Tasks). So the complexity of interface compatibility is increasing. This is why a more robust exception handling on the input and even filtering on the output may be required.
NOTE: I am not asking that Aspose.Tasks fully support all of these other tools ... just provide a complete and safe implementation of the various MS Project XML Schema -
Re: Requirements for development...
I'm also learning about a new definition of 'Test Driven Development'. All I was suggesting in some of my other notes, is that by sharing your plans (at a more detailed level) I will have a better idea of what has been developed and what is remaining and priorities for solutions - rather than learning from my customers that something has not been implemented yet or potentially damaging a customer plan and then requesting an emergency 'new requirement'.
I do understand the complexity of product development. I also understand that if you want to develop using Agile principles that even more transparency / visibility is required about requirements, capabilities of the current version, and priorities needs to be shared with your users.
Thanks for your efforts...
Regards, Bruce