>Not that I entirely disagree, Rick, but .Net versions try to pre-fabricate (I prefer the term automagic) everything as well. Look at the default endpoints for REST in Framework 4.0 as opposed to the hand-rolling in 3.5. I agree also that there are developers who are afraid to look into new technologies, mainly I think because they find something that works like DataSets and stick to them.
>
>There's really nothing wrong with "if it ain't broke don't fix it". I have a WCF/REST app I've been working on for several months. On the consumption side I use all manner of XML consumption - LINQ to XML, XML to DataSet, hand-parsing XDocuments. I suppose I could have coded the consuming app to use nothing but LINQ to XML but I was more efficient working with what I already knew where there was no tangible benefit from going bleeding edge in all areas.
>
>Another note on examining new technologies: I think MS is really messing up in this area lately. The help files are so atomic and there are very few soup-to-nuts examples for a new learner to digest the whole of a new technology. .Net apps are layered technologies and help on a given namespace or type will only go so far in helping someone but almost all we have are granular help entries.
>
>I work with several developers and our running joke is that if it ain't AdventureWorks or PUBS you won't find a good example and 1/2 of those you do are wrong anyway. Look around - how many LINQ to XML examples out there simply omit that you need to preface an element name with XNamespace???
>
>
On PluralSight.com you can find in LINQ technology discussed depth. Not free, unfortunately.