OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS