tdog.blog

Hi there! Welcome to our blog. Don't forget to sign up for our free RSS feed. We Triple Dog Dare Ya! And thanks for visiting!

Wow, in just 33 hours (give or take), we’ll be starting over with a brand new year. It’s gonna be 2004–hard to believe. I’m a big science fiction fan, so of course I’m a little disappointed that here we are, hanging out in the future sans any of those cool personal jet packs, daily ferries to the moon, and little shark fins on cars (although the VW Jetta has a very sharky looking antenna on top of it).

One thing is for certain, though, the Web is racing into the future just about as fast as it can. Now that all the hype and market focus is looking elsewhere, the family of technologies that comprise the Internet are starting to make a difference for companies of all sizes. Many folks who haven’t been paying attention to what’s been happening will be mightily surprised at the ways we’re saving money, time, energy, and everything else with this peculiar medium.

So here’s my first annual attempt to prognosticate the future–and yes, next December, I’ll revisit some of what I’ve said now to see how right (and wrong) I was.

1. Most of the effort put into the Web during its first 10 years of development focused on publishing information for human consumption. There are millions of web sites out there providing all kinds of information in every conceivable info-niche, but hardly any of it is structured in any way.

This lack of structure makes it very hard for computer processes to communicate with each other–after all, computers don’t have our ability to make wild guesses at what this number or that string of letters means. The next few years will see an increasing focus toward structured documents (such as XML) to make it possible for computers and computing processes to interact more efficiently. We’ve already begun to see this happening with Web Services, and companies all over the world are starting to realize that millions and billions of dollars in savings are possible from such efficiency.

2. Because sharing information was the primary focus of the Web in its early years, a great deal of technology arose to meet that focus–namely, content management systems and tools that made it easier to create Web content. In the coming year, sharing computing resources will start to take on more and more importance. Grid computing, already fairly active in the academic and research worlds, will finally feel the benefits of emerging open standards. Companies of all sizes, and eventually consumers, will have access to affordable supercomputing horsepower. If we can figure out how to monitor it, secure it, and charge for it. In the meantime, there’s still plenty to do with Web Services.

3. If COMDEX 2003 showed me anything, it was that the desktop PC is long gone as the sole viewing platform for Web content. Smart phones–capable of surfing the web, fetching email, and working as a PDA–finally have the right size screens. Tablet PCs–light, ergonomic, and powerful–finally have enough oomph and pen computing smarts to help around the office. My friend Barbary Brunner of Microsoft showed me her SPOT watch (that’s Smart Personal Objects Technology). It’s basically a wristwatch that gets news feeds, stock tickers, weather, and oh yeah, the time from Web sources. In the future, Microsoft is planning on adding lots of other content streams as well.

What do these three trends spell for Web development consultants? For one thing, we’re going to have to design for a lot more viewing platforms besides IE and Netscape. We’ll have to structure more of our content as XML or database content and then transform it into the appropriate formats. And we’re going to have to think beyond the needs of content publishing and examine other ways that Web technologies (such as extranets and Web Services) can save our clients money.

I’m looking forward to 2004–the Web has come a long way in the past 10 years, and finally we’re starting to see the kinds of stable technologies (XML, mobile devices, etc.) that will allow the Web to leap beyond our expectations.

Bookmark:

Comments(0)

Without XPath, you really can’t control XSLT (and other XML technologies) with any kind of granularity. To draw an analogy, working with XML technologies without a knowledge of XPath is like trying to understand databases without knowing SQL.

Just like SQL, XPath is a query language, but its syntax is more closely related, in some ways, to regular expressions. At the same time, it’s also a syntax that defines structural parts of an XML document in notation that is similar to file paths.

For example, if you were working on a UNIX machine and I told you to open up the following file, you’d know to look in your current working directory:

File.xml

However, if I told you to look in:

../File.xml

You’d know to look in the directory “above” your current working directory.  Similarly, if I told you to look in:

/home/File.xml

You’d go all the way to the root of your directory hierarchy and then look in the /home directory for the appropriate file. We all know, instinctively that these three file path notations could be pointing to the same file or to three completely different files, depending on our current working directory.

XPath works in much the same way. You can always grab the root element of a document like this:

<xsl:template match="/">

With XPath, you could match all elements that share the same name:

<xsl:template match="//title">

Or you could match only certain elements, depending on their context within an XML file:

<xsl:template match="memo/title"> 

<!—- only grabs title elements belonging to a memo  element -->

You can retrieve elements using the “.” and “..” notation as well. Predictably, “.” is shorthand for “the current node” and “..” is shorthand for “nodes that are children of this node’s grandparent”.

If XPath were just good at retrieving nodes based on a path, that would be terrific. However, XPath also allows us to be more discriminating with our searches. For example, we may want to retrieve only those elements that have a certain attribute value set:

<xsl:template match="title[@priority=’hot’]"> 

<!-- only grabs title elements that have a priority  value of hot -->

The @ symbol in front of priority designates that we are searching on an attribute value. What if you want to retrieve all title nodes that have any priority value set:

<xsl:template match="title[@priority]"> 

You can even mix and match. Here’s how you pick out all the date children nodes of title nodes with a hot priority attribute:

<xsl:template match="//title[@priority=’hot’]/date"> 

Notice that you can also use similar notation to find those elements that have a certain value. For example, let’s say that in a slightly different schema, we are storing priority values in XML elements, not attributes. If we want to retrieve all the title elements that have a priority element set to hot, here’s how we’d do it:

<xsl:template match="//title[priority=’hot’] "> 

All we have to do is drop off the @ symbol and we can work with the value as stored in an XML element.

Here’s how you retrieve the first and last nodes in a group:

<xsl:template match="memo/title[first()]"> 

<xsl:template match="memo/title[last()]"> 

You could also select the first node with:

<xsl:template match="memo/title[1]"> 

Or even:

<xsl:template match="memo/title[position() = 1]"> 

In other cases, you might need to select multiple branches in the same document. For example, here’s how you might pick out memo titles and authors at the same time:

<xsl:template match="memo/title | memo/author"> 

You could, of course, select all nodes in a certain context with *:

<xsl:template match="memo/*"> 

As you can see, the XPath query language is powerful and flexible—it allows you to retrieve just about any combination of nodes you need, and that can make all the difference when you’re working with XSLT and other XML technologies.

Bookmark:

Comments(0)

Customer: Spinal Concepts
Problem: Spinal Concepts needed a better way to track how and when they got product information out to their sales force.
Solution: We built them an extranet powered by our CMS.

Spinal Concepts is an innovative company that builds medical equipment for spinal surgery.

Their global sales force needs current information on the latest products, kits, and systems so they can sell effectively. They also need to get their hands on demo kits so they can demonstrate the power of Spinal Concepts solutions first hand.

Spinal Concepts asked us to build them a state of the art extranet portal. The portal tracks each salesperson by their unique ID, and gives them access to a variety of services:

• Quota numbers by product and month.
• An interactive dictionary of Spinal Concepts products
• Content pages for each product in their inventory, powered by our CMS
• A request tracker that allows sales personnel to make requests for different kits–and allows the request administrator to monitor kits in up to 7 status stations, including shipped, late, and committed.
• Access to their own accounts, so they can keep Spinal Concepts updated as to their current phone numbers, addresses, and other vital information.

The result: a dramatic reduction in time, money, and energy trying to coordinate the different product information rollouts. If the sales person needs support, they go to the extranet first.

Bookmark:

Comments(0)