Welcome!

Industrial IoT Authors: William Schmarzo, Elizabeth White, Stackify Blog, Yeshim Deniz, SmartBear Blog

Related Topics: Industrial IoT, Microservices Expo

Industrial IoT: Article

Programming & Design: How to Reduce the Burden on Web Designers

Leveraging designer tag libraries

The whole point of teams is to allow different specialties to complement one another and achieve the extraordinary, so it can only be a good thing to reduce the barriers between them. This article shows how to eliminate the interdependency between HTML design skills and XML processing.

XML is being applied on all business fronts for internal and external data exchange, transcoding between domains, archival, and powering dynamic and sometimes real-time Web sites. Yet all this technological weaving ties together more than just data; there's also a human aspect. Engineers trade schemas and specifications between one another, and each engineer is expected to understand and be able to integrate those specifications. This, of course, is an accepted facet of our lives, but it belies a problem.

As XML usage has grown ubiquitous, so has this web of dependency. First between software engineering and data modeling specialties, and lately into design fields such as Web design. Designers are increasingly required to integrate Web page designs with presentation of XML data sources.

This has created a market opportunity for tools such as Altova's Stylevision product. Stylevision is a singular achievement that allows a Web designer to visually craft data-driven Web pages, with the end result being not HTML but instead an XSLT style sheet capable of transforming XML instance data into the desired page. Thus, software is provided to hide the increasing complexity of the design task (see Figure 1).

All server-side languages, from Perl CGI scripts to Python, provide a means to embed data in a page (see Figure 2). However, all these languages are deficient in their ability to separate the work of the designer from that of the Web programmer. The inventors of XSLT recognized that creating HTML from other forms of XML data would be a powerful tool and gave us the simplified model of XSLT.

Neither the simplified model nor the full-blown version alter the notion that there is a single file that contains both transformation and presentation elements. The remainder of this article will show that XSLT can be used to elegantly separate the concerns of the programmer while supporting those of the designer.

The Goal

Initially, server-side HTML consisted of procedural code placed in blocks that were somehow escaped out of a regular HTML document. With the advent of XML and XHTML, the trend has been toward using new tags similar in appearance to HTML. The HTML is still well formed.

We'll build a similar tag library using XSLT. A transformation file will be created that can be applied to merge an HTML presentation document with an XML data document. Any tags used in the HTML document will be replaced according to the design of the tag library. If no tags are used in the HTML document, the output will be similar to the input. Furthermore, the tag library will be domain specific and thus meaningful to the Web designer.

Reasons for Using XSLT

By limiting the data source to an XML document, we lose all the flexibility of the general-purpose tag libraries, but in return we also gain many benefits. Designers will find this XSLT-based solution easier to use than the other server-side solutions because:
  • The designer does not have to work around arbitrarily complex server-side code.
  • Web browsers can display local files without having to understand server-side directives.
  • Transformations can be automated on the client side using live or test data.
  • It can be integrated with graphical design tools such as Macromedia's Dreamweaver.
Furthermore,
  • This solution can leverage XML/XSLT accelerator technologies.
Decoupling developer from designer
Our solution does not come with the baggage associated with embedding a general-purpose language. The simplicity of Listing 3 as compared with Listings 1 (PHP) and 2 (JSP/JSTL) is gained by moving all the logic into the XSLT style sheet. Listings 1-10 can be downloaded from www.sys-con.com/xml/source.cfm. (Listing 3 is well formed but not valid because XHTML documents contain only XHTML markup. After undergoing the XSLT transformation we are going to create, it will be valid, too.)

Any server-side solution that requires a single document to contain configuration or general-purpose code will suffer this bloating to some extent. The distinction is more obvious when using the verbose DOM extensions in PHP4 than when using others. In fact, the PHP page must also load the data XML document to process, but I omitted that for brevity.

The XSLT-driven form offers the designer a level of legibility by default that is far greater than that offered by a general-purpose server-side scripting language.

WYSIWYG IDE integration
Most XML-aware IDEs allow you to view an XSLT+HTML page in a browser as it would be seen in multiple live situations, but not to edit the live view. Similarly, HTML WYSIWYG designers can usually handle HTML with embedded scripting, but require a test server on which to execute the script and hence to see the result. This solution is compatible with both types of tool.

Macromedia Dreamweaver allows you to add custom tag libraries through the Tag Library Editor (see Figure 4). Each tag can be manually added to Dreamweaver, or one of the many tag library file types can be imported. This includes support for loading XML Schemas.

Accessing Live Data

The document() function is implemented by the major XSLT processors (at least Saxon, Xalan, and Microsoft's). It allows an XSLT transformation to access XML outside of its primary input. The document function acts as an alternative root in XPath expressions and can even be assigned to variables. I highly recommend using the document function to load a top-level variable, and then referencing the variable elsewhere. In XSLT processors that load the entire target URI, this ensures that only one access is made - a major optimization.

Working locally
The difference between the two forms of custom tags in Listing 3 is in how expressive you want to be. Browsers ignore tags they do not understand, but continue into them when rendering. The upshot is that the designer can easily see what the live page would look like. For example, Listing 3 would be displayed locally as:

"Product Name {product}. Price is ."

After the transformation, "{product}" would be replaced with the actual product name.

Testing locally
Usually you will obtain your working data from a source other than a live feed. However, this is no more complex than passing in a different URL to the XSLT transformation. (The ability to select the source document was intentionally added to the design.) No more uploading to a test server just to test a simple data change, and you can batch up multiple mock data files to be run as unit tests or for the designer to see the page in use in various situations.

The same XSLT transformation that would execute on the server side can be performed with the command-line modes of tools such as Saxon or Xalan. For a more user-friendly approach, many XML-aware IDEs (e.g., Borland and Altova) allow you to configure transformation scenarios that can be applied with just a few clicks.

Leveraging XML/XSLT accelerators
XML accelerators are an emerging type of hardware device that allows XML documents to be routed based on introspection of the data. Recently, XSLT accelerators have turned up that can perform ultrafast XSLT transformations (e.g., the DataPower XA35 XML+XSLT Accelerator). There is no such hardware accelerator technology for server-side scripting.

Implementing an XSLT Tag Library

Figure 3 shows the designer segregated from coding and data-modeling tasks, and left dealing with only our design schema, an artifact of the coding effort. The data and design schemas are elevated to true contracts between specialties.

The design schema specifies the set of designer- and domain-oriented tags available. To add live data to a document, the designer would just drop in one of these tags. At some point we perform an XSLT transformation that removes those tags and replaces them with actual data.

Our task in this article is to create the merge.xslt file that will perform the replacements. To continue we're going to need some live data.

You'll find that Listing 4 shows a simple XML file containing some neat facts about the solar system. (An XML Schema for this file is available at www.sys-con.com/xml/sourcec.cfm.)

Simple XSLT Copying

When an XHTML page is fed into a style sheet with no templates, the input is stripped of all elements and only text content is output. So the first step is to create a style sheet that performs a copy without modifying the document, at least not functionally. (The page is completely rewritten by the transform, so some minor changes may be experienced as an artifact of this process.)

Listing 5 shows an XSLT style sheet for copying XHTML. The <xsl:output/> tag causes the XSLT processor to indent the output and to represent the output as a strict XHTML document (this only affects the document type processing instruction). The single template matches attributes and any node, and copies it to the output stream as we require. This copier is the foundation upon which we will build our data-merging system.

Replacing Designer Tags

The next step is to intercept those tags in the input that we're interested in. Our designer tags are distinguished from XHTML tags through the namespace to which they are assigned, so we add these namespaces to the style sheet. Now we can create a new template that will react to one of these designer tags. We'll pick a simple one to start with, an element that inserts a copyright string into the output.

This modification will cause any copyright tags (which must be in the namespace http://xml.grumpykitty.biz/designer/stars/1.0) to be replaced with the copyright string (C) 2004 Grumpy Kitty Productions.

The XSLT document() function is used to access our data source. We must remember to add the data namespace to the style sheet.

Listing 7 shows a full style sheet that disregards its input and instead outputs the number of planets in the Sol system. The style sheet is decoupled from the source by passing in the URI as a style sheet parameter. This allows us to maintain Sol system data for multiple universes.

This style sheet will ignore any of its standard input and merely output the number of planets. Here is a sample command line for Xalan:

java org.apache.xalan.xslt.Process
-IN empty.xml
-XSLT mergedata.xsl
-PARAM dataSource solar.xml

Listings 5, 6, and 7 are easily combined to copy XHTML documents, replacing designer elements with live data.

Tags Within Tags

The complexity arrives when we try to represent relationships within the data set. We could specify separate tags for Star n, Planet n, Moon n, and so on. More realistically, we can provide tags for the designer that represent repeating elements in the source data. Whereas previously our designer tags were replaced with real data, these tags are not replaced with anything. They serve only to identify portions of the template XHTML page that should be duplicated for every data point. I call these tags grouping nodes.

Given this XHTML fragment:

<body><ul>
<star:planetGroup>
<li>Planet: <star:name /></li>
</star:planetGroup>
</ul></body>

The intent is that all of the tags within the <star:planetGroup/> should be duplicated for each planet in the input data. This includes both XHTML and designer tags.

Grouping Implementation

Every time we reach such a grouping node in the template XHTML, we must duplicate the entire contents of the grouping node for each matching data point. However, the grouping node itself should not be copied.

Iteration over the source data is performed with the <xsl:for-each/> element as shown in Listing 8.

Note: The standard "dot" operator is overridden by the <xsl:for-each/> element. To work around this, I store the current node (i.e., the <star:planetGroup/> node in the XHTML document) in a local variable.

The duplication performed by <xsl: apply-templates/> is different because we must first lose the <star:planetGroup/> node and record the current data point from the source data. We can do the first by creating a separate template that just skips the <xsl:copy/> element and specifies mode="ignore".

Preserving the current source context is a little more complicated. The XHTML document being copied is arbitrarily deep, and we cannot use top-level variables for this purpose because parameters and variables in XSLT are immutable. Instead, we pass the current source context node(s) as one or more template parameters to every copying or grouping operation. Grouping nodes can then use variable hiding to specify new contexts. Listing 9 shows this technique in action.

Groups Within Groups

There are at least three semantic groups within our source data: stars, planets, and moons. Each of these groups must be maintained with <xsl:with-param /> and <xsl:param /> pairs. This must happen during the copy and during <xsl:for-each/> iterations.

The notion that moons are tied to planets, and that planets are nested within star systems, is embodied by the declaration of the <xsl:for-each/> element. Just as we can iterate over the contents of the document top-level variable, we can also iterate using the variables holding our context. Listing 10 shows such a template for the <stars:moonGroup /> grouping node.

The following code sample shows a leaf template that places the orbit of the current moon into the output by referencing the newly established moonGroup parameter.

<xsl:template match="designer:moonGroup//designer:orbit">
<xsl:param name="moonGroup"/>
<xsl:value-of select="$moonGroup/orbit" />
</xsl:template>

In this implementation it is very easy to add new leaf designer tags, and a little more complicated to add new groups. From the designer's standpoint, some of the XHTML is simply wrapped in a new, obviously custom, tag. When viewed after the transformation, the XHTML has been duplicated as many times as there are data points. This lends itself very well to building XHTML tables, lists, and so on.

Simplifications and Optimizations

Skipping XSLT template parameters
I've mentioned that all grouping and copying nodes must take the group parameters and pass them through. This is only the case if they are needed further down the XHTML tree. For the closest parent grouping node to a simple designer tag, this is almost certainly true. On the other hand, these simple designer tags may only need to access one of the several parent groups. Not every little piece of information about the moon needs to reference the earth!

Reusing designer tags
To simplify use of - and minimize the number of - designer tags, we can replace designer tags in the XHTML based upon their location. For example, <stars:name/> can be replaced with the name of a moon if it is under a <stars:moonGroup /> grouping node, and with the name of a planet if it is under <stars:planetGroup />.

This result can be obtained by:

  1. Using <xsl:if /> or <xsl:choose /> to conditionally test for context
  2. Using quite complex XPath statements to determine context
  3. Using additional template parameters to track context
For the example given above, solution 3 can be used. The new template parameter (called latestGroup here) must be added to the duplication template. Every time a grouping node is encountered, the latestGroup variable is hidden with the current iterated values.

When processing reaches our designer tags, the latestGroup parameter always contains the correct node in the source data and is simple to use:

<xsl:template match="designer:name">
<xsl:param name="latestGroup" />
<xsl:value-of select="$latest
Group/data:name" />
</xsl:template>

In the source distribution, you'll find examples of all three solutions.

Potential Issues

The primary issue with this solution is speed. XSLT transformations can easily create a bottleneck, and this solution uses XSLT extensively. If your data is rapidly changing, I recommend using a hardware accelerator or another solution. I highly recommend creating unit tests that enforce timings during development.

Also, the document function steps outside the bounds of the XSLT environment. This may expose you to nuances of the host environment. Ensure that your host environment and the XSLT processor play nicely together.

Integration

The main purpose of this article is to alleviate work on the designer's part. To this end, the designer's tag library we created can be used within IDEs such as Macromedia's Dreamweaver. To do this, I created an XML Schema that specifies the set of designer tags; however, the schema import functionality leaves a little to be desired. A workaround is to create a mock tag library descriptor file (.tld) that can be imported. It's also possible to create an XSL transform to perform this conversion.

Download the source distribution to find the dreamweaver.tld file and follow these steps inside Dreamweaver:

  1. Select Edit>Tag Libraries from the menu.
  2. Click the + icon and select JSP>Import from file.
  3. Browse to and select the dreamweaver. tld file from the distribution.
  4. Click OK twice, and you should see the new tag library in the list.
This XSLT method can also be integrated with the Apache Cocoon XML publishing engine, and this is the environment under which it was originally developed. Apache Cocoon treats publishing a document to the Web as a pipeline; at one end XML is sourced, and at the other XML is serialized into a byte stream. This article has detailed a method that allows us to have both XHTML template documents and native or custom Cocoon data sources.

Other XML-enabled IDEs and production environments should be similarly capable of integrating this solution.

Looking Forward

In this article I have described a method to offload work from the page designer onto the back-end developers. We used standard XSLT to simplify a designer's access to live data.

The additional layer of separation can be used to perform calculations outside of the page design and data model, to isolate the designer from data changes, and to allow for unit testing.

Although we focused on creating new designer-oriented tag libraries, the core data-merging techniques are applicable to processing any XML document, and even any tag. One particularly cool application I wrote using these techniques deals with manipulating an SVG drawing at publish time based on a dynamic XML data feed. I'm sure many of you will be able to blow that away with your own ideas!

Feel free to e-mail to me with your comments and observations. A full implementation of this technique and supporting files for ANT, JAXB, Eclipse, Dreamweaver, and Apache Cocoon is available for download at http://xml.grumpykitty.biz.

Reference

  • XSLT Quick Reference by Mulberry Technologies: www.mulberrytech.com.
  • More Stories By Peter Allan Horsfield

    Originally from the UK, Peter Allan Horsfield has been developing software for over 15 years. First in the engineering and automation industry, then later in the energy commodity industry, and since 2007, as a project manager crowd-sourcing development for various companies through TopCoder Inc.


    Between 2002 and 2003, Peter worked on a project to deliver real-time radar processing data to distributed web-based clients, building on the Apache Cocoon XML framework. Peter's article on the topic was published in Web Services Journal in 2004.


    Peter Horsfield is a graduate of the Johns Hopkins Whiting School of Engineering MD USA, and the University of Warwick, UK. He now lives outside of Philadelphia, Pennsylvania with his lovely wife and daughter.

    Comments (1)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    IoT & Smart Cities Stories
    Dion Hinchcliffe is an internationally recognized digital expert, bestselling book author, frequent keynote speaker, analyst, futurist, and transformation expert based in Washington, DC. He is currently Chief Strategy Officer at the industry-leading digital strategy and online community solutions firm, 7Summits.
    Digital Transformation is much more than a buzzword. The radical shift to digital mechanisms for almost every process is evident across all industries and verticals. This is often especially true in financial services, where the legacy environment is many times unable to keep up with the rapidly shifting demands of the consumer. The constant pressure to provide complete, omnichannel delivery of customer-facing solutions to meet both regulatory and customer demands is putting enormous pressure on...
    IoT is rapidly becoming mainstream as more and more investments are made into the platforms and technology. As this movement continues to expand and gain momentum it creates a massive wall of noise that can be difficult to sift through. Unfortunately, this inevitably makes IoT less approachable for people to get started with and can hamper efforts to integrate this key technology into your own portfolio. There are so many connected products already in place today with many hundreds more on the h...
    The standardization of container runtimes and images has sparked the creation of an almost overwhelming number of new open source projects that build on and otherwise work with these specifications. Of course, there's Kubernetes, which orchestrates and manages collections of containers. It was one of the first and best-known examples of projects that make containers truly useful for production use. However, more recently, the container ecosystem has truly exploded. A service mesh like Istio addr...
    Digital Transformation: Preparing Cloud & IoT Security for the Age of Artificial Intelligence. As automation and artificial intelligence (AI) power solution development and delivery, many businesses need to build backend cloud capabilities. Well-poised organizations, marketing smart devices with AI and BlockChain capabilities prepare to refine compliance and regulatory capabilities in 2018. Volumes of health, financial, technical and privacy data, along with tightening compliance requirements by...
    Charles Araujo is an industry analyst, internationally recognized authority on the Digital Enterprise and author of The Quantum Age of IT: Why Everything You Know About IT is About to Change. As Principal Analyst with Intellyx, he writes, speaks and advises organizations on how to navigate through this time of disruption. He is also the founder of The Institute for Digital Transformation and a sought after keynote speaker. He has been a regular contributor to both InformationWeek and CIO Insight...
    Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
    To Really Work for Enterprises, MultiCloud Adoption Requires Far Better and Inclusive Cloud Monitoring and Cost Management … But How? Overwhelmingly, even as enterprises have adopted cloud computing and are expanding to multi-cloud computing, IT leaders remain concerned about how to monitor, manage and control costs across hybrid and multi-cloud deployments. It’s clear that traditional IT monitoring and management approaches, designed after all for on-premises data centers, are falling short in ...
    In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
    Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...