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

RE: Who's right? Security-centric or Character/Language-centric orUser-I

  • From: cbullard@hiwaay.net
  • To: xml-dev@lists.xml.org
  • Date: Thu, 17 Apr 2014 12:19:08 -0500

RE: Who's right? Security-centric or Character/Language-centric orUser-I
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?"


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