Kirk Evans Blog

.NET From a Markup Perspective

CSS Zen Garden

CSS Zen Garden

  • Comments 6

I have been doing less and less with XML at my clients lately.  This is not completely by my customer's choice, either:  much of it is driven by me. 

As a background, my role within Applied Information Sciences is Software Architect, following the roles defined in the Rational Unified Process.  This makes me responsible for the overall design of a system and the integration plan for subsystems.  I also function as a Lead Designer, which makes me responsible for designing the subsystems that I previously identified.  I also function as the Database Designer as well as Implementer.  This pretty much means I participate heavily in the Analysis and Design phase to develop the Software Architecture Document, then mentor teams of 5-10 people through the construction phase.

When I start a client engagement, I try to get a feel for what the customer is comfortable with as well as what the customer is interested in exploring.  The usual suspects that they are familiar with include basics of C#, some DataGrid work, maybe even a user control or two for ASP.NET apps.  Sometimes I am pleasantly shocked to hear what they have done with .NET, but more typically they have stuck to basics. 

Then I ask what they are interested in.  Within the first few moments, I hear that they want to do something with a web service.  Typically they will indicate a desire to create a suite of reusable ASP.NET controls.  Almost certainly, someone mentions the need for a centralized security framework, and given enough time someone will toss in requirements for developing a standard application portal.  And all of this they want thrown into yet another 6-week project titled “Customer Relationship Management Tool“. 

Parting the overall architecture dream from what can actually be accomplished in 6 weeks can be an art form, one of paring a mountain of granite down to a 5-inch perfectly shaped bust of Shakespeare.  Time to start the inception phase to see what they really want.

Once I get started looking at what they are really asking for, I see no mention of web services, controls, security, or a centralized portal. They usually just want some basic data capture and retrieval behaviors.  These requirements are captured into a few use cases.  We are supposed to stay away from implementation details at this stage, but you cannot help but notice that there still is no need for introducing web services yet.  Worse, you can't imagine much more than a 2-tier app that Infopath could serve just as well as a custom ASP.NET app.

Once we are done defining the use cases, we define the realizations through sequence diagrams.  You ask a few clarification questions:

Me:  Is all of the data contained within this single database?
Client: Yes.
Me: Do any of your external customers need access to this data?
Client: No.
Me: Are you interacting with any other platforms, maybe calling a Java app on a Sun box running Linux?
Client: No.

We just went through the basic premises of how to make the call if web services are appropriate or not.  In this case, web services serve no apparent need.  OK, maybe you can think of one or two odd situations for web services that this dialog doesn't cover, maybe using the IE Web Service Behavior for DHTML updates to the UI without page refreshes.  But this does serve 90% of the purposes for web services.  So why do people overuse web services so much?

I talked with a local Microsoft Evangelist, and he indicated that web services were definitely the future for .NET.  And he said it with a straight face:  I think he really believed it.  Sadly, I think many of the developers lured into .NET also believe it.  Hell, the marketing description for .NET describes it as Microsoft's platform for building next-generation web services.  You can't work with .NET and not hear about web services.

Maybe someone at the web services team at Microsoft has a much different view of service oriented architectures, but that view won't soon be realized in the corporate world without making the cost of server licenses much less an impact to small and medium sized company's financial statements.  They don't typically have farms of servers waiting to be utilized, and they typically don't have many external customers that they want to share data with.  They have a pool of secretaries doing something manually that can be automated with a small investment.

Web services are great, don't get me wrong.  But they just don't apply to many of the applications that are actually being built.  That doesn't mean they are not being used.  I have seen web services used for component to component calls on the same box.  I asked the developer why he chose to implement a web service there:  his answer was “it sounded interesting.“  OK, he is not getting the AM Turing Award anytime soon, but you have to wonder why web services sounded so interesting that he would defy reason just to throw one into an otherwise healthy application.  In a word, “marketing.“  He bought the marketing hype, he drank the kool-aid, but more importantly he needed “web services“ on his resume somewhere.

Now go back out into the real world of developers where people have been programming for awhile, maybe using COM or Java successfully for several years.  Mention “web services“ to many of them, and you will hear a giggle, maybe even a guffaw.  “Web Service!?!  What are you trying to do, cripple our systems?  Slow 'em to a crawl?  We don't need no stinking web services!“

The fact is that many of the clients I interact with do not have web services in place, nor do they need them. But their managers have read so much about web services and XML that they insist that web services are the only way to develop systems these days.  The lesser experienced developers grab hold of every little bit of neat technology they can get without a bigger picture of the impact to a system.  The more experienced developers are more grizzled and callous to “technology for technology's sake.“

Not so mainstream, but definitely related, is the guise of XML.  XML has its place, definitely has its many uses.  The configuration framework (a future post will explore the overuse of the term “framework“) within .NET is a prime example of how XML can be properly used.  DataSets can use XML Schemas to define strongly typed DataSets as well as to coerce hierarchical data into relational objects.  But just as soon as I list the benefits of XML, someone is sure to follow with a question like, “what is better, XML or a database?“  There are folks who see through the marketing and the hype, and the others who are stopped cold in its tracks.

XSLT never really suffered the same track as XML or SOAP.  XSLT is difficult to approach, because you need to have a grasp on XML, namespaces, and XPath.  There is a larger barrier to entry for XSLT than XML, where you can pick up the basics after reading aquick article on  The remaining complexities of XML can be hidden by the DataSet.  SOAP has been rendered deceptively simple by the existence of the [WebMethod] attribute in .NET, almost unnoticeable to those who develop web services.  But XSLT... nothing really hides XSLT yet.

Nothing made XSLT easier, and this is one of the reasons that it has a comparatively slow adoption rate.  To note, this is why you see so little about XSLT in the way of books and articles.  Why write (better yet, why publish) for such a small audience? If nobody is using this stuff, why write on it?  If there are so few articles in the mainstream rags about XSLT, why use it in my applications? 

A few tools, like Marrowsoft's Xselerator, ease some of the burden of working with XSLT, but you still have to know a lot about XSLT to really leverage the tools. 

And when do you use XSLT?  Since I develop mainly web applications, people typically want to use XSLT for controlling dynamic screen placement or branding applications.  Take a look at CSSZenGarden:  This is one of the best demonstrations of why XSLT is not always the answer for this. 

XSLT has its uses, but they are waning in my architectural style.  The more I architect solutions that developers are able to construct and maintain, the less I introduce XML and XSLT.  The fact is that developers just don't use them enough to understand them as viable tools.  They know the marketing terms, they know the objects that hide deeper implementations.  They don't know XML.  So I am forced to develop less elegant yet equally effective solutions to problems using other means.

Thank God there are always Design Patterns left to confuse them with.

  • I'll be interested in the comments you get on this post Kirk. Pretty much I'm in agreement with you. The _only_ use I've found as yet for web services is straddling firewalls.... SOAP uses port 80 and removes just about every headache for me.

    I do believe there are other uses for SOAP and web services - just nothing currently in practice. Now, XML? Many, many uses. Want to persist an ADO recordset? XML. Want to use syndication on your website? RSS - or rather XML. Want to render the exact same source in a browser using the DOM (client- or server-side) or in a Word processor or a spreadsheet? XML - particularly using MS Office 2003. How about the cousin of XSLT... XSL-FO to render XML as a PDF?

    Web Services... the jury is still out. XML... mainsteam since it is (1) human-readable, (2) platform independent and (3) platform pervasive. Sure, if you work in a COM or CORBA shop you may not find many needs to use it, but if you want to integrate yourself with most any other platform and/or shop out there (and just about everyone MUST do this) XML is the best way to go.
  • This may be a stupid question, but isn't "CSS Zen Garden" about CSS design rather than XSLT?
  • Woody, the reason I mentioned CSSZenGarden is that it shows (and quite well, I might add) that CSS handles structural presentation of a web site wonderfully. CSS is typically a much better candidate for altering presentation aspects than XSLT because many user agents do not support XSLT on the client. In contrast, most user agents strive for CSS compliance. The typical use for XSLT is controlling HTML rendering, when the opposite should be true: more forethought should be given to the structure of the HTML markup so that CSS can easily be applied to it. XSLT is typically the wrong tool for the job here.

    Dave, thanks for your comments. I agree that XML is mainstream, but there are not a set of best practices that involve XML. More often than not, posts in newsgroups revolve around trying to make XML function as a database, and people become disconcerted with the lack of multi-user support in the DOM. Why people try to fit the square peg in the round hole, I don't know, but I see a lot of posts asking about locking issues on an XML file on a web application and how you would use an XML file to support hundreds of users for updates simultaneously.

    I would love to architect an enterprise system and integrate multiple platforms using web services and/or XML with validation. But the sad fact is that there just aren't many of those applications being built.
  • I like CSS too, but let's admit first it's just completely different beast and actually cannot be compared with XSLT (say CSS can't sort articles by date or create TOC as it's only about presentation of existing data). Secondly CSS support in browsers is still toooo poor unfortunately (Tim Bray has ranted about it on his ongoing - IE doesn't support CSS2 and sounds like it won't. And W3C is preparing CSS3 already!
    And for the rest - I agree with Kirk. That's bad idea to design a system with "Where to put XML/Web Services/etc here" in mind.
  • "The typical use for XSLT is controlling HTML rendering, when the opposite should be true: more forethought should be given to the structure of the HTML markup so that CSS can easily be applied to it. XSLT is typically the wrong tool for the job here."
    Yeah, but where HTML markup comes from?
    Hey, do you want to say the data should be forethought structured in a way to make the presentation easy????
  • "[XSLT is] just completely different beast and actually cannot be compared with XSLT"

    For how the typical user would implement XSLT, it can directly be compared with XSLT. How often do we answer questions on coloring every other row in a table using a mod operator? <a href="">CSS can control alternating table row color</a>, but most implementors would throw this logic in XSLT. In fact, this is often a driver for using XSLT instead of using static HTML or simply rendering the HTML dynamically without embedding style.

    XSLT can be used for sorts and numbering, but more typically users want grouping and don't want to invest the time to learn about Muenchian grouping. The most typical use of XSLT that I am seeing in newsgroups is for reporting applications, and the poster usually starts out with "I am just starting learning about XML..." Which goes back to the point that nothing has yet successfully made XSLT easier.

    "Do you want to say the data should be forethought structured in a way to make the presentation easy?"

    Actually, yes: this is exactly what I am saying if you consider the "data" to be the HTML markup and the "presentation" to be the styling of the markup. I know it borders on heresy, but I think the point is one to consider. HTML should be used for page content, and CSS used to control style and layout. Instead, XSLT usually serves both purposes: rendering the HTML and embedding style within it.

    There does exist an opportunity for a peaceful coexistence of XSLT and CSS. I just am not running across many with these same thoughts.

    These problems are further exacerbated by Front Page and VS.NET's HTML WYSIWYG designer that inlines style attributes. It almost reinforces the concept of poor page design through ease of use. You have to fight the designer to avoid inlining styles!
Page 1 of 1 (6 items)
Leave a Comment
  • Please add 4 and 2 and type the answer here:
  • Post
Translate This Page