"enterprise" projects always have a DBA, someone who works with the database underneath, usually an Oracle or SQL server database expert. Sometimes they can be hard to work with, because they treat us developers as ignorant idiots who don't understand how to design databases properly for performance and data purity. We resent them, but need them, because they not only get our apps to work, they ensure quality and longevity of the data. And they write really good SELECT statements. Alternatively, "the enterprise recognises that data is often more important than individual programs"

I'm starting to wonder if we are going to need some similar role in the future for XML binding, the XBA. This would be a person who understands XML namespaces, XPath complexity, how to write XSD, Schematron and RelaxNG schemas, and maybe even when and how to use RDF. They would give you the efficient Xpath paths, schemas that worked, and WSDL that interoperated.

No such role formally exists. You get 'XML experts', but its not assumed that any project needs a specialised XML expert the way they need a DBA. Instead everyone still falls for the lie that adding @WebService or [WebService] makes your class interop. Nobody would realistically do an enterprise application with the database table bindings defined by the developers, declared in the EJB annotations and magically interpreted by the runtime -yet nearly everyone is prepared to let the Web Services stack do that for messages.

Why is it that the structure of data in the DB of a single application is valued more than the structure of messages between applications?