RE: [xml-dev] The Information Interchange Profession (was: XML As Fall G

["Len Bullard" <cbullard@hiwaay.net>]

Different jobs certainly require different skills and facts at hand.   The cause of XML, IMHO, is not to fix the understanding or lack thereof.  It is there to make it not matter in so far a a clean syntax and a notional tree can do that.  For machines, not quite enough information, for humans, the tedium of adding semantics to syntax and revising both. 

 

XML systems at large are very much hands in the cookie jars toolkits.  It is there to provide a representation however realized in the iron that conveys the set of information the creator intends and the consumer has to accept or reject.  Note, I did not use the word, producer, because it decouples intention from output.

At heart, the web is based on the notion that a creator and consumer are blind.  In practice, that’s ,,,, bull.   We work with probably more and more precise instructions than almost anyone in the enterprise when it comes to validating product.   XML is A QA practice:  a rigor of preparing data such that misunderstanding is rare if done to specification.   This is why S1000D and SharePoint are a cock up.  Because it doesn’t handle XML easily and natively (at least as well as say, Arbortext). It forces a just-in-time QA-capable editor to the end of a process where it cannot by virtue of that technology and the practices it entails, impact cost and quality,  It forces a double loop though the val-ver, an increased cognitive load in terms of tools, templates, skill sets and hands to produce the same information.  It does that to force MS Word and other office tools to the front end of the information flow where they are least effective.

That’s dumb. “)

 

Why?  S1000D is ONE of a set of technical information data and namespace (not XML Namespace – the S1000D namespace ground out by S1000D task analysis.  Use them in order, and logistics and technical information creation and management Just Work.   It is a morphological generator indexing a family of related module types via a weakly typed set of topical codes (information codes).   The advantage is it types the text requirement for the consumer.   XML is consumer oriented regards quality.

 

SharePoint fights that.  Makes it redundant and awkward.  All the while, MS Word is itself, a SharePoint klutz.  Trust the Edit Button?  So now a system that claims to be very good at meta-data driven file management corrupts files.  At the most obvious point of entry for the user.

 

That’s dumb. “)

 

I think if as a list too often computer sciency, we lose focus on process as jobs we know we have to do over the tools we use.   Being XML-Dev, where some of us are tool builders, sellers of tools and so on, it has traditionally been déclassé to push product.   On the other hand, in a conversation about jobs at hand, that some of us who are tool users have to do every day, claims made on solutions and Viking boasts have merit.   Gather at the docks and talk cock ups and missions.

 

IOW, a work focus.

 

len

 

-----Original Message-----
From: Peter Hunsberger [mailto:peter.hunsberger@gmail.com]
Sent: Monday, December 09, 2013 3:34 PM
To: Hans-Juergen Rennau
Cc: Kurt Cagle; Steve Newcomb; xml-dev@lists.xml.org; David Lee
Subject: Re: [xml-dev] The Information Interchange Profession (was: XML As Fall Guy)

 

 

In my opinion, the concepts of nodes (= location + content) and path expressions (= navigation between nodes) are fundamental to IT, so fundamental that their understanding should be required from a person regarding himself as an IT professional.

 

Once more; this is graph theory and graph traversal, it's a well defined  part of Computer Science with extensive underlying mathematical principles.  I'm not sure that means all IT professionals need to understand it.  I've worked with many great UI and UX pros and many Business Analysts who really have no need of it.  However, if you are doing anything that touches algorithms then yes you need to at least know the basics.  If you're designing data structures you should at least know what differentiates a graph from something that is not a graph and why that matters (ie; relational databases vs. key value stores).  Unfortunately the reality is that this stuff is pretty abstract and hard to teach.  Bridging the gap from the pure theoretical to the hands on building of programs that are used to teach computer languages isn't really done.  We've touched on it previously before on the list, but to me this is the dividing line between "programmers" and Computer Scientists.  I don't think you always need the latter, but I do agree that the world in general needs to know the difference and why it matters.