Ken says: "Q: How is XML like violence?
A: If it isn't working for you, then you aren't using enough of it."
Usually true.
I'm slowly but surely being convinced that SharePoint-As-CSDB is
actively harmful. It creates a lot of human process overhead and
loopbacks for the sake of bean counting and avoiding XML. It looks
smashing somewhat like certain British sports cars (and some American:
say Corvette) but for all the muscle and flash, the nimbleness is
lost. To use another metaphor, it's winning a season in the weight
room only to face a team that is small, fast and doesn't have to
huddle before every play (say endless meetings). And once set up, if
there are errors, dammed hard to rethink.
On the other hand, there are lines not worth crossing. XI:INCLUDE is
one. If DOCTYPEs aren't a problem and the modules are consistent,
entities work just fine, cheaply and for less programming.
It isn't always the case that the organization has the right tools and
in these cases understanding XML-Out-Of-The-Box is a big help. There
is a presumption in some specs and projects that the web tools are the
only or best way to get jobs done. When building Off The Web
products, those presumptions are actively harmful.
Then there is the FOSI. It is supposed to be dead but it only smells
funny. I've looked at the processes people are using to build S1000D
documents using XSLT pipelines and they are a lot of work where a FOSI
can do the job with fewer lily pads as long as you have an editor that
can produce the output format (say PDF). Now if the XSLT tools are
the tools at hand (say the Github style sheets) and you are happy with
the dm-to-db-to-docbook-to-FO-to-pdf steps, have at. It simply isn't
necessary. A FOSI can do the job in a single bound.
Then there are the assumptions of the schema designers. S1000D's
dmRef is an example. It's a way to annotate the morphology but as an
identifier, it isn't useful and assumes post-processing. It's way to
store the components of identifiers but it's like tossing a relational
table into the middle of a table of contents and saying "figure this
out in situ". So we toss code at that and it works but it means a
publication module is worthless without the extra code. An XML
document with a set of proper entities works out of the box. YMMV but
it means avoiding some S1000D bits like the PM until you have to pass
it along and even then, you're passing on the problem to the next guy.
IOW, we often are hired to use the tools at hand and we have to be
sharp enough to do that. This is really what distinguishes the
experienced experts from the resume experts: knowing the difference
between XML and systems that use XML. The Web IS A System. Full stop.
As said, horses for courses.
len
