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


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.


[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