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-dev] The Social Phenomena that Leads to a Diversity of Data Formats and the Ensuing Data Interchange Challenges

I had a similar experience about half a decade later (or maybe not but half-decade *technology* later)
I was in charge of the Campus Student computers.   A recent "Modern" replacement to the VAX/780s ...
(which were in turn a replacement to the IBM/360 which went its merry way to JPL where it might still be in use today ... who knows).
The "modern" replacements were 4 x   DataGeneral MV4000 "Mini computers".
Only 2 fridges tall instead of 5 ... 

One day one broke and we had to call the tech (suit, tie, briefcase etc).   He came in and went with his list of diags to perform which he admitted were not in order of likely failure, but in order of cost to replace...
( hardware was still more expensive the human time).  He tried booting the computer (no boot).
The first question he asked me was "Did you turn the power off ?" ... Very sheepishly I said "What do you mean" ... The power was obviously ON ... he asked again ... "Did at any time you turn the power off ..."  ... <duck> "Yes" ... "Oh well where do you store the microcode tapes .... "  huh ??? 
Turns out you couldn't boot the device from power-down state to even the normal OS boot  ...
you had to boot Microcode FIRST which loaded in the microcode and only then could you boot from the OS tapes ...   It had never crossed my mind that microcode would be in volatile memory ... 

David A. Lee

-----Original Message-----
From: Cox, Bruce [mailto:Bruce.Cox@USPTO.GOV] 
Sent: Monday, August 22, 2011 3:43 PM
To: David Lee; 'Costello, Roger L.'; xml-dev@lists.xml.org
Subject: RE: [xml-dev] The Social Phenomena that Leads to a Diversity of Data Formats and the Ensuing Data Interchange Challenges

When I learned Fortran in college, a computer lab technician managed an inventory of all the locks on campus using punched cards and the glorious IBM 1130 complete with Selectric keyboard input device.  His code was on the cards as well, "dumped" to punched cards each time he revised it.  Loaded very fast, but if the IBM guys came in and rewired the back plane (1. Remove jacket; 2. Remove vest; 3. Remove back cover of 1130; 4. Spread out the paper wiring diagram; 5. Remove wires from back-plane pins as specified; 6. Add wires to pins, taking care to route as specified; 7. Fold up paper wiring diagram; 8. Restore back cover of 1130; 9. Put on and button vest; 10. Put on and button jacket), the code stopped working.  At that point he'd retrieve his source deck, compile, and dump again.  "... exactly the same machine ..." is no exaggeration.

Oh, rats, I forgot to include "roll up sleeves" and "roll down sleeves."  It was a ritual with them.

Bruce B Cox
Director, Policy and Standards Division, OCIO, USPTO

-----Original Message-----
From: David Lee [mailto:dlee@calldei.com] 
Sent: 2011 August 17, Wednesday 15:08
To: 'Costello, Roger L.'; xml-dev@lists.xml.org
Subject: RE: [xml-dev] The Social Phenomena that Leads to a Diversity of Data Formats and the Ensuing Data Interchange Challenges

Not sure what this has to do with "Social Phenomena" but your description
sounds accurate to my memory of 40 years of software development.   And it
mirrors not just data formats but also code portability.
I was lucky at a young age to have exposure to a wide variety of OS platforms and the concept of writing software (then it was "C") so that it
was "portable" was ingrained.   Yet almost everyone I met had no such
concept ingrained.  The near-sighted wisdome was 'This will only every run on this one OS/Machine I'm writing it for so why should I put the extra effort into making it "portable" ? Its a waste of time '

Now that Data is the New Software I think the same rationale applies.

Still not sure how this ties in with "Social" ... to me its more a matter of expectations, experience, and thinking ahead beyond the 1 inch in front of your face.  And be willing to take the extra effort and *suffer* the performance costs of portability.
I remember when it was considered "Efficient and Really Cool" to simply take a literal memory dump of a program and save it as an "a.out" format to save
state.    It was quick, efficient, and actually worked.  It only took a few
lines of code to save the entire program AND its entire set of data.  You could launch the saved program and it picked up where it left off.  Fast !
No reading in data files, no serialization.  No abstractions.  It just re-launched your program back in the same state as when it was left off.
The Height of Genius.

Except of course it was an awful hack that only worked on exactly the same machine as it was run on and only worked on a very few OS's and then was extremely prone to bugs and hacking.  But hey.  It was Very Cool Solution to a Real Problem.

David A. Lee

-----Original Message-----
From: Costello, Roger L. [mailto:costello@mitre.org]
Sent: Wednesday, August 17, 2011 1:53 PM
To: xml-dev@lists.xml.org
Subject: [xml-dev] The Social Phenomena that Leads to a Diversity of Data Formats and the Ensuing Data Interchange Challenges

Hi Folks,

This is fascinating [1]:

The way software is developed has led to the situation today where there are
various data formats. Programs are very often written speculatively, that
is, without any advance understanding of how important they will become.
Given this situation, little effort is expended on data formats since it
remains easier to program the I/O in the most straightforward way possible
with the programming tools in use. Even something as simple as using an
XML-based data format is harder than just using the native I/O libraries of
a programming language.

In time, however, it is realized that a software program is important
because either many people are using it, or it has become important for
business or organizational needs to start using it in larger scale
deployments. At that point it is often too late to go back and change the
data formats. For example, there may be real or perceived business costs to
delaying the deployment of a program for a rewrite just to change the data
formats, particularly if such rewriting will reduce the performance of the
program and increase the costs of deployment.

The result? Many applications, each with their own data format, e.g. binary,
text-not-XML, and text-XML.



[1] Section 1.1 of http://www.ogf.org/documents/GFD.174.pdf 


XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[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