Re: [xml-dev] The Social Phenomena that Leads to a Diversity ofData Form

[cbullard@hiwaay.net]

> 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.


Even more interesting is the case where  a single specification or  
standard for a data format (in olden terms, an application language)  
comes to govern multiple systems after the initial release for a  
specific application.   Over time it grows and becomes unwieldy.   
These are easy to spot using DTD technologies because they are heavily  
parameterized.  IOW, you may not rewrite the software.  You keep  
expanding the data set.  Then the problem is knowing which subset to  
deliver per delivery per phase of the schedule (think CDRLs).

I spent the morning de-parameterizing one of these *completely*.    
When viewed in fully expanded state, you see all the opportunities for  
error introduced by expectations of the customer not matching their  
own citations in the Statements of Work.   Tools handle these by  
relaxing the completeness checking requirement (essentially, turn  
validation off) but that negates the advantages of structural  
authoring (less knowledge required of the author at each step or phase  
of production).  In effect, to use both the DTD and the tools  
effectively, someone subsets the DTD per production phase and tightens  
it or loosens it accordingly while ensuring that the end validation  
meets the final deliverable requirements (think phases CDRLs).

Sounds good.  How many pubs organizations have someone capable of  
doing it?  Probably not many.   What are the results?  Val/Ver is  
messy, noisy and the fact of how deliverables have to be scheduled by  
policy and process pushes the project over schedule and budget.  It is  
the hand can't touch the elbow on the same arm problem.

If aircraft were developed the way software is: the first test pilot  
is guaranteed to die on the first flight with a decreasing number over  
the test cycle of flights, then a planned number of passengers perish  
until the number of deaths per release of upgrades to the aircraft  
meets an acceptable planned number of dead for the lifecycle of the  
series.

len

Quoting "Costello, Roger L." <costello@mitre.org>:

> 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.
>
> Comments?
>
> /Roger
>
> [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
>
>
>