Re: XML As Fall Guy

From
<>
To
Date
2013-11-26T21:37:26Z
ID
<>
Thread
Re: XML As Fall Guy
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.

Caveat emptor.

len