OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   markup anti-pattern

[ Lists Home | Date Index | Thread Index ]


Here is an example of XML application design *in the wild* so to speak.

                                  *

The principals of a small ISV have done their homework.  Formerly
employed in their target market, they have an excellent grasp of the
requirements of the domain.  They have built a comprehensive
relational data model and a very clever servlet which manages access to
the database, debugs SQL queries, serves JSP or ASP to the client and uses
dom4j to help the junior developers rapidly whip up new business objects
guaranteed to communicate well-formed XML.

There is no comprehensive mapping between the relational model and the
markup model.  This is seen as *leveraging the best of XML technologies*
by simply avoiding the famous costs of markup.  Each XML instance is
created ad hoc by the junior dev building a particular facet of the
application, even casing is left to the discretion of the developer
because *XML is easy (TM)*  This apparently is sufficiently unburdensome
in such a small shop as to be a profitable development model.

Looking for new ways to leverage the best of XML, the principals hit upon
FO.  Hmmmmm, printable PDF reports.  For a while, each developer writes
her own FO just as she writes her own JSP, which makes perfect sense
because she's writing her own markup.  But FO is so verbose, so obtuse.
One of the principals finds himself picking up the slack with increasing
frequency.  Hire a stylesheet author.

This individual's stated job description is to write what is termed
*static FO* for the develpers while they are knocking up the markup and
the JSP.  Static FO means building an FO page in situ, if you will,
without reference to any XML data at all, with placeholders for eventual
data.  The twain meet when tens or hundreds of three foot long XPath
statements are formulated and cut into the static formatting objects
document.  It is extensible, it is a language, but is it markup?

What is to be done?  How can the humble *markup wonk* communicate what is
wrong with this picture to the CSci PhD and DBA who conceived it?  They
have achieved developer efficiency, of a sort, and cleverly avoided the
*costs of markup*.

They are quite congratulating themselves.

                                   *

I submit that this model is not nearly so uncommon as we might like to
believe.  Indeed, I wouldn't be so hysterical if not for the way it so
closely rhymes with my experience of SGML.  Then, the tool vendor,
conscious of the sensitivity of their clients to the *costs of markup*,
sprinkled backdoors throughout the application.  Inline presentation
macros with nary an angle bracket were liberally applied in production and
validation was an inside joke.

Validation.  Indeed, in ten years before the mast, I have never had the
opportunity to work professionally with a markup model (beyond the
representational standards: HTML, FO) that wasn't conceived and
implemented solely at the discretion of an individual programmer.  And 9
of 10 that model existed for only a brief moment at the requirements phase
of system development because ignoring it was such a clever way to avoid
the *costs of markup*.

Does this not constitute something very like the worst of markup?  It is
the worst of something.

----------------------------------------------------------------
Mike Haarman
mhaarma@socsci.umn.edu





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS