RE: XML in publishing. Was Re: Memorable quotes from Balisage2013

[cbullard@hiwaay.net]

Technical publishing is what I'm doing and some XML system challenges are:

1.  Get clean text and other items out of wysiwyg sources for use in  
markup.  It isn't a problem with databases but there are the little  
niggling issues of character sets etc. that still require time.  Very  
few shops of writers actually use XML to produce writing.  They use  
Word or something like it and then an XML wonk does the rest.  XML is  
a requirement of the contract.  Otherwise they would tar and feather  
anyone who suggests it.  While we may have a lot of theory for why it  
is a "good thing", they don't need it.

2.  Get a rock solid rendering engine that doesn't work with the last  
version of the software and fail in the next.  Again, mostly little  
issues but time consuming.  FOSis work ok although the system that is  
most famous for applying them documents them only in terms of it's own  
GUI and tedious to build when the toolkit can only work with a subset  
while the XML is using a ton of microparsed strings for the clever  
bits so the editing of the XML is delicate.  Debugging becomes very  
old school very fast (a known problem of data driving).

3.  Getting the web out of the pipeline.  XSLT is good for what it  
does but if one isn't publishing to the web then the namespaces  
infrastructure is not nearly as useful and in some configurations,  
actively harmful.

Not all digital products are targeted to the web.  Distressingly most  
XML production products are.   It is often the case that one has to  
print reliably from the same resources and that means PDF.  It is  
often the case that one needs minimal but reliable linking for  
navigation with a history list, that is, the basic hypertext features  
without the web.

After the time and resources expended to create architectures for  
advanced IETMs was expended it became evident that the end users hate  
IETMs and really want a navigable book from which they can print a few  
pages then head out to the flight line to do a task.   At this point  
in evolution it is now the web that is too complex and overkill for  
the job.  They need less GUI and higher fidelity information, fewer  
moving things on the screen and a page with a few controls that stay  
stable from release to release.

The point in aggregate is many publishing shops are not programming  
shops and the one size fits all nature of XML systems is they need  
programmers.  They want the XML to "just work" and "work RSN because  
hours are being burned waiting".  I listened to a logistics manager  
who is actually a smart and talented guy turn the air blue saying  
(paraphrased to remove the blue), "There is no **** way writers or  
managers should have to know any of that **** stuff." in response to  
an explanation of the difference between XSLT and FOSI and why S1000D  
and 24784 are incompatible structures.   They simply want a  
chapter/section book that tells them how to remove and replace a part.

The programmer is no longer the information king.  The data designer  
is.  Weird how that worked out.   The positions since 1994 are exactly  
reversed.

len