[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Is programming sexier than data design?

  • From: cbullard@hiwaay.net
  • To: xml-dev@lists.xml.org
  • Date: Tue, 11 Mar 2014 10:35:01 -0500

Re: Is programming sexier than data design?
Frank says: "You have to do a lot of programming to make up for crappy data design."

Boy, howdy. Or just the subtleties of humans in the loop who enter the information, or are upstream creating tools and don't actually read or understand the data design. Real cases, S1000D related for real world examples:

1. The folk creating the Data Module Requirements List (DMRL) containing the Data Module Codes (DMCs) are SharePoint/Excel folk. The DMCs are "ugly" because they have dashes in them; so they take them out. The codes are stored in the data module reference element as attribute values. Programmer has to put them back in (think Split function). An implementation detail, but... or they load the code values with commas without reckoning with comma separated value data formats internal to a compiled tool downstream. Again, an implementation problem so solvable (schlepping HTML tables internally or creating special format classes is ugly but reliable).

On the other hand...

2. Logistics "expert" who creates the codes never reads the S1000D specification and doesn't know that the codes are validated as patterns. He removes the subSubsystem code because "he doesn't like it". Because the codes serve as filenames and as ids internally, he breaks the namespace all the way across the project.

3. Because of bad process design (same person or persons doing both and fully ignorant of the XML Schema requirements because they can't read them), specs all of the tools to use the bad design while reducing the actual process of the XML creation and editing to "messing with the ASCII". He then runs the project for six months with these hidden flaws. Every bit of information in the project relies on these codes, they are disseminated widely as is and they have never been through an XML validation pass. Not once.

Oopsie.

What the programmer faces is not simply bad data design, but bad data design, incompetent processes, hidden code, hubris and arrogance. Humans in the loop who do not and will not accept that a specification that relies on XML to deliver is inherently an XML specification and that claiming they can do their jobs without knowledge of XML are walking the beaches heads up, proud and smiling just before the tsunami. The only wall between them and the roaring sea is a programmer.

Caveat vendor.

len


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.