RE: Who's right? Security-centric or Character/Language-centric or User-Interface-centric or Data-Centric?

Of course, they all are at different times and with different  
strengths in different projects.  My perspective at a particular time  
for a particular project:

1.  Security Expert: my project is for Off The Web.  His role is to  
secure the location, the machines, sneakerNet (containers) and the  
humans.  If he fails, there is not a thing I can do about it.  Off the  
Web doesn't mean non-web.  Using web tech and web formats, but  
file:/// instead of http:// because the transport systems (say the  
Internet) are just too risky.  On the other hand, a web control is a  
solid rendering system and as long as I am careful with the linking,  
it all works.  IOW, awareness is critical but security is not my job.   
My problems would be HUMINT not SIGINT and that is a game in most  
scenes best played by well-trained experts not amateurs.  See Mrs.  
Peel.  On the Web, this guy IS the most important and not  
understanding that in the initial design and fielding of the Web is  
why The Web Is A Catastrophe.  YMMV.

2.  Unicode Expert:  he is at least two nodes in front of me.  If he  
didn't do his job, mine will fail in subtle and surprising ways.  It's  
more an issue for me to detect when he failed because if he succeeded,  
everything just works.  If he failed and worse if the  
node-fetcher-maker-designer fails because of him, a single  
character/space will blow the house down.  Say <!DOCTYPE root[.

3.  GUI designer: he is me and me is he and he and me and the data  
designer are tied together at the hip.  If the data design is bad, the  
GUI can cover that up a little bit with clever code (see multiple  
events/single handler).  If the data design is smart, the GUI falls  
out of that pretty smoothly.  This is a framework gig and as much art  
as science with lots of decisions for when and where to click and how  
often, when to validate at entry vs later during composition, which  
controls are best and how to reuse them vs replicate classes (say  
multiple gridviews vs modes and state tracking; aka, who's zooming who).

The snake in the grass in this job is if the Illustrator GUI Makers  
(art majors who know how to drag and drop) get in the mix before the  
event-to-handler-to-data relationships are worked out.  See SharePoint.

4.  Data designer:  this is the guy with the most challenging job.   
The No Size Fits All: Some Sizes Fit Most rubric applies here.   There  
is a laundry list of issues discussed here and elsewhere that apply.   
Attribute vs element, pattern facet vs redundant attributes,  
namespaces vs OR groups, JSON vs XML, morphology vs element tree,  
yadda.  String vs double or int, etc, is easy for most cases.   Trying  
to avoid casting too often and/or redundantly is a matter of bad habits.

So if I have to pick the one that even if not most important is most  
"influential" (can cause the most people the most pain or pleasure),  
it's the data designer because a bad data design that is sealed in  
paraffin is fixable but if sealed in amber is expensive to explain  
when it must be violated.  For this reason, I prefer XML with a DTD or  
schema that I can adapt as needed and apologize for in the business  
rules.

BTW: you left the business rule expert out of the list and He Is The  
Devil Incarnate.

:) "lenisms" and all that jazz...

len

Roger sez:

"The first person was a security expert. He told me, "Security is the  
most important thing. When designing an application or system, your  
design must place security first; create a design centered around a  
secure foundation."

  The second person was a Unicode expert. He told me, "Character and  
language issues is the most important thing. When designing an  
application or system, your design must place character and language  
issues first; create a design centered around a good  
character/language foundation."

  The third person was a user interface expert. He told me, "The user  
interface is the most important thing. When designing an application  
or system, your design must place the user interface first; create a  
design centered around a good interface foundation."

  The fourth person was a data (XML, JSON) expert. He told me, "Data  
is the most important thing. When designing an application or system,  
your design must place the data first -- the core piece of design that  
you need to get right is the data model; create a design centered  
around a good data foundation."

  Who's right?"