RE: [xml-dev] [ Revision #2 ] 15 elementary truths about XML

["Cox, Bruce" <Bruce.Cox@USPTO.GOV>]

Very many years ago, I was called upon to introduce a small group of librarians to microcomputers.  I drew a few boxes, put a large box around them, and then briefly described how those boxes interacted to produce what one saw on the screen or a printed page.  A crude, but useful abstraction for the purpose at hand, but not something one would submit to the ACM for publication.

Roger's elementary truths, it seems to me, are intended to do something similar, that is, help someone with no concept of XML to see how it connects to things they might be familiar with, like binary numbers, bytes, characters, etc.  An abstraction useful for the purpose, but not intended for post-grad students.  The reactions here to Roger's suggested path through the various technology layers supporting XML makes it clear that not all of us have the same conceptual map of this territory.  On the contrary, while our maps overlap, some of us have much greater detailed knowledge of certain areas, while for others, some areas are known only from their travel brochures (that would be me).  

(One of my great pleasures in following this group is to discover just how much I don't know by reading the discussions that Roger provokes, and using them to fill in the gaps in my map.  They remind me of a master's class conducted by, say, Luciano Pavarotti.  Singers of all levels benefit from witnessing his one-on-one interactions with top-ranked newcomers.)

I'm guessing that the condition that Len describes is a consequence of putting complex tools in the hands of folks whose map of technology layers is a wilderness, so sparse they perhaps don't even have the same continents yet.  They retreat to what they know, what they do have in common, a cultural safe harbor where the abstractions driving XML are literally off the charts.  I have found that the greatest obstacle to implementing XML-based content is getting people to think differently about the content.  Specifically, to deal explicitly with structure previously submerged, at that's on top of getting them to deal with the technological hierarchy that supports it.

I wonder whether the OSI model, or some amplification of it, would be a helpful framework for the elementary truths about XML.  In the course of introducing attorneys to oXygen so they could use it to edit the Manual of Patent Examining Procedure and the Trademark Manual of Examining Procedure, it would have been helpful to have something to represent the scope of the universe and locate within that the very small place where they were suddenly expected to operate knowledgeably and efficiently.  Some years ago, Kenneth B. Sall created a map sketching the relationships among the various specifications touching on XML for his book "XML Family of Specifications : A Practical Guide." (Addison- Wesley, 2002.)  But that represented just one valley in a much larger territory that one has to traverse in order to exploit XML.  

Bruce B Cox
Director, Usability & Design Division, OCIO, USPTO
571-272-9004


-----Original Message-----
From: cbullard@hiwaay.net [mailto:cbullard@hiwaay.net] 
Sent: 2011 November 3, Thursday 11:53
To: Rudder, Doug Jr
Cc: Costello, Roger L.; xml-dev@lists.xml.org
Subject: RE: [xml-dev] [ Revision #2 ] 15 elementary truths about XML

As I've been discussing with Betty, these gaps create production inefficiencies in publishing, in particular, technical publishing where a logistics group is producing very large (in excess of 1200  
pages) manuals based on complex (for some n of complex) DTD/Schemas.    
Using WYSIWYG to produce the content and then having "taggers" produce the XML creates errors, redundant entry, and increases costs.  I'd love to see a trade study that analyzes costs of using the common operating system resident editing tools and the tagging approach vs having an integrated development toolkit across the logistics enterprise.

I repeat:  the CALS vets and I include the web community that followed them should go back and clean up the bigger project that spawned most of us.  If you toss the inability of so-called "taggers" who can enter data but can't analyse the markup, read the DTD/Schema much less debug the XSL/FO/PDF process, it is questionable what the value of XML is and yes, it is being questioned despite the fact that the ability to create multiple post-tagged products from it is well proven (see paper.format vs frame.format in ETMs and IETMs).  It is as if we recreated an even more redundant version of the 1970s/80s tech pubs  
groups that employed an army of stenographers and technical typists.   
That was the problem we were trying to solve and somewhere we lost the thread of that initiative.

len

Quoting "Rudder, Doug Jr" <Doug.Rudder@wolterskluwer.com>:

> Len said:
>
> "And the failure of American universities to grasp the importance of 
> adequate XML training for technical writers is sustained and abysmal.
> They turn out editors who can memorize Word style sheets but they fail 
> when it comes to providing enough knowledge to bridge the gap between
> writers and elementary computer science concepts.   Roger fills the
> gap.  Ken fills the gap.
>
> And that is a good thing."
>
> This is true; hence the presentation I originally gave back at XML 
> 2001 on XML and Technical Writing, based on experience in the XML 
> adoption at the company I work for (SGML originally in 1993).
>
> Most of our editors and authors came from a desktop publishing 
> background. Separating content from style was a brand new mindset that 
> was difficult to foster. I count myself in that group at the outset (I 
> started as an editor and morphed into a content analyst/programmer 
> over time). It wasn't until I was assigned to a project repurposing 
> our data that the "creative tagging" issues and lack of understanding 
> became apparent. Trial by fire, as it were, but a valuable learning experience.
>
> It even came up later when I was teaching a night class in technical 
> writing at SIUE. One of my students had been briefly exposed to XML in 
> an authoring environment and was questioning its value. It led to a 
> lively and productive discussion. We went totally off-track for that 
> evening's writing topic, but it was worthwhile nonetheless. :)
>
>
>