Hi again,
That's a very interesting statement by the MOSS instructor. SharePoint is a great website collaboration tool but it isn't a good XML store because it is list based. Collections don't work well, so if you have any structure (repeating child nodes underneath a parent node, for example), the default display options in SharePoint won't work. You'll have to write code to shred them to separate lists. That is very doable, and it would be cool to implement, but why bother when SharePoint already includes SQL requirement as part of the install. Just use the same SQL database to define a proper relational database and shred to that without code. That's what I'd do.
Don't get me wrong. InfoPath and SharePoint are a great combination, but don't expect to use SharePoint as a relational database displaying the data in your XML. You could do it, but it's a lot of coding and probably not very scalable in terms of number of items. If you absolutely must use InfoPath and SharePoint to display relational data you can create separate dashboards forms in InfoPath that use xpath to extract and report on data in other InfoPath forms using either import or just SharePoint web methods.
Good luck!
Patrick Halstead
Project Manager at Qdabra