Simon sez: "Whatever the underlying story, I suspect we'll be dealing
with the reverberations from this for a while."
This and a lot of other minor earthquakes. If one has worked in a
shop or shops that rely heavily on SharePoint, one notes a loathing of
XML. Why?
1. In MicrosoftLand, XML is a programming language, meaning, if
someone clicks on a link, it will try to open Visual Studio as it's
editor.
2. SharePoint has evolved into a drag and drop system where much like
the ACA web site, the illustrator/graphic designers who fancy
themselves to be UX designers have come to dominate. They don't like
non-WYSIWYG environments much and usually don't understand non-HTML
XML applications. They, as they tell you, don't do "backend" work.
The problem is with SharePoint, no one else is doing that either.
This is fine until they are in an environment where XML is mandated
for good reasons. Then they tend to set up the workflows to avoid the
XML by pushing them to the other side of some imaginary process wall.
All of the authoring and verifying (say quality checking) gets done in
say MS Word. If XML is a requirement, it gets done at the end by
being tossed over the wall to taggers the same way our parents tossed
yellow pad manuscripts to the typing pool.
It works ok until a loop back to the authoring occurs. Now the
SharePoint introduces a twisty tangle of revision/issue version
control problems. Worse, it is possible that customer-mandated
processes such as validation/verification are never applied to the
deliverable. They are applied to the Word files. Everyone thinks
they've done the quality steps, but they haven't. They don't
understand what goes on when XML documents and say CGM graphics are
assembled or the opportunities for missteps.
If you're doing something like an S1000D project where lots and lots
of pieces of documents (say data modules) are being assembled into a
master document with the potential namespace issues (not XML
namespaces, the garden variety kind), this can be very expensive and
can outright fail.
And this doesn't get into the process design problems where the
SharePoint designer designed the workflow too tightly too early (same
early binding of late known project requirements).
Caveat vendor.
It is a very big deal that procurement folk and their paymasters are
issuing requirements without understanding the technologies so they
really aren't doing a very good job vetting the proposals or the
vendors.
