Older blog entries for simonstl (starting at number 16)

The mixed content flashpoint

Mixed content - where text nodes are mixed in with element nodes - seems to generate a substantial share of anger. When developers talk about simplifying XML, mixed content is usually one of the first things to go, and many developers effectively subset XML in practice by creating vocabularies that use more atomic approaches to content, wrapping all text nodes in separate elements.

Mixed content itself is not exactly dire. Most humans use it all the time when creating documents in markup - HTML and DocBook both use it constantly. Treating text as an equal to structure may seem perilous in worlds where structures are privileged, but I have a hard time seeing it as functionally a problem. (I'll acknowledge that using mixed content to represent object structures may seem aesthetically disturbing to those who believe their structures are and must always remain tightly structures.

The limitations placed on mixed content in XML DTDs are extreme, permitting only constraints on which elements may be mixed with text, and no rules about their sequence or need to appear. W3C XML Schema uses complex types to represent mixed content, providing finer control over the order and appearance of the elements but giving no control over the text save permission for it to appear. RELAX NG offers both the uncontrolled approach of DTDs (with its mixed and interleaved content) and much finer grained control of text nodes through its text pattern. Mixed content's reputation as an uncontrollable bearer of complexity may be nearing its end.

I've been working on several Java filters for working with text in XML documents. One of them (ool) completely removes the text from XML elements and replaces it with references to a separate text file. Another part of that filter offers an element wrapper for the text nodes in mixed content. I'll be poking around in the textual side of XML for a while to come, and hopefully I'll have code worth showing this week.

Marking up

The "markup" in "Extensible Markup Language" is worth closer examination, as markup and markup approaches have their own set of principles which are rather different from other forms of information modeling and representation. While many developers consider XML document formats containers they fill with information, there's a reverse view of that which also needs to be considered.

In this reverse view, the information is primary. It's sort of a "in the beginning was the word, not the markup" perspective. In some ways it makes the most sense with documents, but it's also pretty easy to do with data, especially if that data is already in some textual form (CSV, tab-delimited, whatever).

"Marking up" information means starting with information and adding markup to that information to add metadata - structures and annotation - to the information. This could mean starting from a plain text document and adding markup information, or it could be a more mixed process, with information creation and markup structuring performed simultaneously.

Markup doesn't have to use angle brackets and XML rules. There are lot of other forms of markup, from wikis to lexical date notations. Mixing markup with content is controversial itself from certain viewpoints, but remains a useful approach for many different projects.

A common view emerges from this process. The view holds that the "content" of a document is the textual content of its elements, with the markup - element structures and the attributes in those structures - merely providing additional information. Stripping out the markup will certainly remove structure and annotation, but in some sense the basic information is still there.

This approach isn't universal by any means. XML doesn't require a particular view of markup usage, nor is it always easy to separate 'base' information from annotation. Developers working with various tools often use the convenience of the tools to determine how they prefer to see information presented in documents. Still, thinking this way is at least an opportunity to question and consider how best to use markup.

SGML for the Web

[I wasn't around for the creation of XML 1.0 - in fact, I've never been on the inside of W3C work, and prefer to keep it that way for a lot of reasons I'll explain here someday. Some explanation of where XML came from seems like a good idea, though. Let me know if you have corrections.]

I first encountered XML in 1997, a few drafts into the process. That first draft I encountered described what became XML as "Part I. Syntax" - the other two parts were Style (eventually XSL, XSLT, XSL-FO, and XPath) and Linking (eventually XLink and XPointer). XML would be much like a simplified SGML, XSL much like a simplified DSSSL, and XLink much like a simplified HyTime. Together these three specifications were going to:

"enable generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML. XML has been designed for ease of implementation and for interoperability with both SGML and HTML."

That description survives even today in the latest edition of XML 1.0. In a lot of ways, XML has been a raging success, but it hasn't exactly lived up to that dream. For the moment, I'm just going to explore what that scenario might have looked like.

Publishing XML documents to the Web is pretty simple, basically like publishing HTML. You upload documents to a server or you generate them at user request, and a browser, crawler, agent, or some other application requests the information.

That part's easy. The tough part comes from XML being both infinitely more flexible than HTML and kind of dumber. HTML browsers know what the HTML vocabulary is: how to identify a headline, a link, an image, a paragraph. A browser working with XML has no way of knowing that information. That leaves developers two choices. They can either convert all their XML to HTML (and to other formats, so it's not a total waste of time) or they can find other ways to express how to style and link their documents.

On the styling side, developers have a couple of loosely-related choices. They can use the Extensible Stylesheet Language (XSL)'s XSL Transformations (XSLT) to generate XSL Formatting Objects (XSL-FO) which then get rendered to PDF, PostScript, TeX, RTF, or some other printable format. They can also use XSLT to transform their XML into HTML. Less intrusive but sometimes less powerful is Cascading Style Sheets (CSS), a technology originally developed for HTML that happens to work very well for XML. Instead of transforming the document, CSS just lets you describe how to present it.

On the linking side, XML Linking Language (XLink) provides some powerful - well, compared to HTML anyway - hypertext linking capabilities. XLink lets you specify links "out-of-line", even outside of the documents they link, as well as in the document HTML-style. XLink's companion standard, XPointer, gives hypertext developers a set of tools for things like establishing links between ranges of text in a document. XLink's been described by its creators as "hypertext ready for the challenges of the 1970's", but it's an interesting set of tools. It seemed to ease my frustrations with HTML without lurching into the complexity of HyTime.

XSL and XLink both took much longer than expected in getting done, though pieces of XSL (XSLT and XPath) got out sooner. XSL reached Recommendation status last October, and XLink last June. XPointer is still in Candidate Recommendation, with seemingly dim prospects. I'd built a Java SAX filter for working with XLink, but pretty much abandoned it as the slow spec continued to change confusingly on its way through the process. There are also some interactions between XLink and styling to sort out.

So how's the combination of Extensible Markup Language (XML), Extensible Stylesheet Language (XSL), and XML Linking Language (XLL, now XLink) done on the Web? Uh, yeah. I did a series of articles for XML.com on XML in browsers (Mozilla Opera Internet Explorer Summary Table) back in 2000, and things haven't changed that much. XML does have some promise, but in rather different directions than expected.

[Yes, I'm writing too much stuff. I don't know why, I just need to get it out somewhere, without much concern for polish or visibility. There's a semi-coherent story under here, that I'll reassemble someday when I have time in a different form. And heck, I'm probably wrong about any number of things. Figuring out which things is the fun part.]

The Web slowed down

While I'm not very happy with either Macromedia's recent moves with Flash MX or much of the recent Web Services hoopla, I don't think organizations are saying "let's take on the Web" because the Web is so strong.

The public face of the Web is the Web browser. For users they are tools, for designers they are traps, and for the Web and Web vendors they're public relations on a huge scale. "Browser Wars" drove designers crazy for a few hectic years as Netscape and Microsoft battled over features, driving other vendors from the field before Netscape ground to a halt. Opera appeared as the battle was fading, but Microsoft had achieved a decisive advantage at version 4.0.

Unfortunately for the Web, the end of the Browser Wars has slowed the development of browsers substantially. Mozilla's done some very impressive work, especially integrating XML, and Opera's developed a loyal fanbase, but Internet Explorer hasn't really changed. It still has very little clue about XML and CSS, no understanding of the XHTML namespace, and pretty much focuses on the W3C's state of the art from about four years ago. (On the bright side, its plug-in model is robust enough to support things like Adobe's SVG plugin, so third-party extension is at least possible.)

At about the same time, HTML itself stopped developing... much. HTML 4.0 appeared in December 1997, with some changes in December 1999. XHTML 1.0, released in January 2000, was only a "Reformulation of HTML 4 in XML 1.0", using exactly the same vocabulary with some minor updates to support differences between XML and HTML practice. XHTML 1.1 broke XHTML into smaller modules, making it possible to create subsets like XHTML Basic and profiles like An XHTML + MathML + SVG Profile, but again, the vocabulary didn't expand at all. (If anything, it's contracting because of the W3C's continuing distaste for frames.)

This slowdown isn't all bad. Recent threads on xml-dev have suggested that the W3C does its best (and easiest) work when codifying existing practice rather than developing specs from scratch. The browser vendors have finally caught up to most of the features from the 1996 CSS1 specification, though the 1998 CSS2 spec is proving much slower going. Perhaps just as importantly, developers who use these specifications have had time to figure them out, without too much fear that they'd be left behind. A few new Web browsers (Konqueror, iCab, etc.) have even appeared.

On the other hand, developers have good reason to feel stuck. HTML forms haven't changed substantively in a long time, and desperately need a revamping. Dynamic HTML went through the Document Object Model process rather than the HTML process, and has had a substantial impact, but many developers still don't find it as flexible or reliable an application framework as something like Java applets (remember those?), Flash, or Curl. XML's impact on the "traditional Web" has been pretty minimal, as Microsoft and some of the smaller vendors have done little to implement the CSS and XLink functionality needed to make XML hypertext possible. SMIL's multimedia support hasn't gotten very far inside the browser, though SVG looks like it's having more luck.

The Web is not all that far from providing the functionality of the client-server tools it displaced, but it seems to have halted a bit short, at least in its most commonly-used form. It's not clear that the W3C can specify its way out of this waypoint, and the implications of a weakened Web seem pretty ominous for other Web-related projects, like the Semantic Web. Projects that go around the Web may find smoother sailing.

That should be troubling for those of us who prefer Web architectures and approaches to new and old "rich clients". It seems to be up to the W3C and (more importantly) its member vendors to demonstrate an interest in keeping the Web alive - or letting it fade. A vital Mozilla project seems like the best hope of restarting a sputtering engine, if it can reach an audience.

the Web as decade-long diversion

Adjusting to the Web was hard. I first came to the Web from HyperCard, so I remember looking at the Web and thinking "wow, this does a lot less hypertext than I'm used to." It took some substantial adjustment to get over that, and in some ways I'm still rebuilding the toolkit I had in HyperCard.

After I had adapted to the Web's implications for my hypertext projects, I realized that the Web had unpleasant implications for a group of developers with very different interests from mine. Client-server developers found themselves seething over the limitations of the Web as their programs and approaches were abruptly dumped by companies who saw promise and cheap software in replacing expensive custom clients with Web-browser front-ends.

The client-server people, who after all represented a much more mainstream set of programming understandings, weren't entirely cut out, as there was still plenty of work to do on the server side, and middleware continued to explode as a category. The Web quite neatly slashed the explicit bonds between the back-end data stores and the front-end client, forcing them to "make do" with interfaces that weren't nearly up to early standards and an approach that delivered information to the client, not a detailed understanding of what to do with it.

The Web really was (and perhaps still is) different. HTML has been, pretty much from the beginning, a means of conveying information. Instead of facilitating, say, function calls across networks, HTML facilitated the presentation of information in fairly large chunks connected by hyperlinks. The HTTP infrastructure was built around those assumptions from the beginning, evolving over time to support optimizations like caching and greater interaction with users.

"Less is more" still doesn't go over well with a large sector of the development community, especially when it comes to separating information from instructions for processing it. While markup-centric communities, whether HTML, SGML, or XML, focus on separating content from presentation and processing, this separation is quite alien to a lot of programming practice, notably object-oriented development. Markup and OOP have very different notions of flexible reuse and graceful degradation.

It's plain that practitioners of the programming practices so gracelessly evicted by the Web now think they've learned enough from the Web to have ambitions of the same kind of success. While they reuse Web infrastructure and even Web consortia, they have little patience for "fairy tails" of Web practice that might get in their way.

Reusing Web infrastructure gives Web Services access to widely-deployed, well-understood, and often sophisticated network libraries, letting its advocates claim that it's cheap. In the meantime, questions about the appropriateness of the toolkit they're proposing, both in general and specifically in relation to how well or poorly it fits on the Web are shoved aside because "everybody's doing it."

I guess that's progress of a sort, for all those oppressed programmers who can't bear to represent their information separately from their plans for processing it. A lot of the Web Services visions I'm hearing lately sound a lot like client-server, circa 1994.

aesthetics across communities

I've been thinking more about my earlier comments on aesthetics and think that maybe I took too simple a view. I value the aesthetics of the underlying XML, but there are lots of people out there who only value the aesthetics of what you can do with the XML - Web Services people are one group, but there are lots of other programmers and database people out there with their own aesthetics.

To those folks, the state of the XML underneath their transactions is "mere" aesthetics. It doesn't affect the performance of their applications in ways they notice or understand. XML-RPC has some bizarre structural anomalies in its parameter markup, but no one cares. I'm reminded of a comment I heard at last year's XML 2001 show: "Why would I go to a Web Services conference? It's not like I need to learn how to use XML badly."

Developers who work primarily with XML focus on document structure, while Web Services developers focus on application structure. It's kind of like the difference between building a house designed for a particular group of occupants (XML) or building a set of houses stamped out identically regardless of who will live there or why (Web Services).

People do seem awfully content to live in Generica, delighted by the aesthetics and cost of carbon-copy houses, malls, and lots and lots of roads. Maybe that's a better strategy for reaching a large audience in any case.

Ports, portals, portholes, pinholes

This may not make sense at first, but diaries seem like a good place to ramble through metaphors a bit.

For most of the early years of the Internet (as TCP/IP was arriving and the ARPANet->Internet transition was going on), the Internet and the computers on it were pretty much wide-open. Developers could build applications connecting an address and a port to an address and a port. With thousands of ports available, a limited number of people actually on the Internet, and a relatively open architecture, this model did quite well for a lot of years.

As the Web arrived and more people starting connecting to the Internet, all those open ports had to be hidden behind firewalls and private - though still TCP/IP - address spaces. Instead of wide-open access, developers created "portals" of various kinds, providing Web-based access to all kinds of information. Instead of connecting directly to the systems with the information, Web sites presented intermediate views. Access to information was now constrained by the portal.

Portals quickly grew huge, as different people in an organization used different parts. Fortunately, simple techniques like bookmarks let people find their way around without having to start from the beginning again. Some developers took advantage of the visibility of URLs to create meaningful and memorable identifier for information as well.

I see Web Services as moving to what I'll call a "porthole" model. Information is available, but through pretty small openings. Instead of the multiplicity of URIs that Web development has thrived on so far, Web Services (on the SOAP model) proposes to use far fewer URIs but let them have multiple services behind them. Less "space" is exposed to the world, but information still flows through that space. figuring out which porthole you want requires either advance knowledge or a query process (UDDI, WSDL) that itself likely (though not necessarily) goes through portholes.

It seems that the landscape for information exchange keeps shrinking. While ports remain available at the foundation, and portal models continue to dominate "traditional" Web site development, portholes are the next big thing. I'm not sure what pinholes will look like.

aesthetics

Today I'm pondering the importance of aesthetics in computing. There seem to be a lot of people out there who are perfectly fine with whatever, so long as it works. If the underlying data or code is wildly inefficient or overcomplicated, it's just fine, so long as what appears in their inbox/object/screen/whatever is what they expected.

I've defended spaghetti code and similar things in the past as necessary. In part it's just that spaghetti code is a step most people have to take on the way to getting a project to work - the emergence of refactoring as a topic all its own suggests that very few people get everything right the first time around. (There are a few, but they seem to be exceptions. I'm certainly not one of them.)

The problem isn't that first efforts are bad. The problem (as I see it) is that first efforts are sometimes cast in stone. Most frequently, this is because no one gets around to fixing them. If it ain't (badly) broken, don't fix it. Occasionally, though, a horrible mash gets canonized as some kind of standard.

That seems to be the case lately at the W3C. Members want their specs and they want them now, giving us charming things like W3C XML Schema and the lightly-modified but still deadly SOAP. While human-readability of markup probably isn't the best or only guidelines of the success or failure of a specification's use of markup, these specs reach new heights in creating XML documents that are actually embarrassing to show to an audience.

It's exasperating to me that XML people sometimes pick on Web developers because they take a more aesthetic approach. Sure, XML doesn't have much room for questions about syntax aesthetics, but there's enormous room for markup aesthetics, and we don't seem to take the time. We should learn from Web developers, not dismiss them.

I've been reading Jeffrey Veen's The Art and Science of Web Design for the last few days, and I'm delighted to see that this book manages to express an awful lot of aesthetic judgments I've shared without being able to explain them. Aesthetics seems a more obvious issue in Web design, with its generally explicit visual approach, but programmers and markup developers could use a similar set of discussions.

Maybe the answer is just to insist that people pay more attention to the aesthetics of what they're creating, even as the impatient howl for anything that works. I don't know how to make that stick, but it seems like it's at least worth considering. Talking about issues sometimes gets people thinking..

What the Web is, and a wannabe

Roy Fielding's posted a clear explanation of the fundamental conflicts between Web Services and the Web, while Noah Mendelsohn seems to think that having ambitions similar to the scope of what the Web has achieved makes something a part of the Web.

Oh, and David Orchard has concluded that those questioning the rightful place of Web Services in the Web and at the W3C have a "reckless and irresponsible attitude".

Funny, I thought I was being quite conservative, in a "conserve the Web rather than take reckless and irresponsible action" kind of way. Or is that just stop energy? I just can't win.

braden asks if I'm depressed by the quality of responses I got to my Web Services article. I wasn't depressed by the first two, who completely missed the point, but I'll admit to being depressed by his comments.

Too many developers seem to be just floating along with the Web Services current, sort of figuring that "everybody's doing it" in a mutually reinforcing march toward the cliffs. No one, even its supporters seems to be able to explain what value SOAP really adds - except, of course, that "everybody's doing it."

Web Services does share one tiny feature with the Web - it cuts across platforms, languages, and pretty much every other aspect of computing. Unlike the Web, its ambitions are enormous, its ownership is uncertain and unfriendly, and its architecture is a mash. HTTP was hackery, but had time to adjust before it reached a wide audience. Web Services is hackery, but its proponents insist on staying the Web Services course as previously charted.

To repeat a point I made replying to braden, "I don't see anyone building Web sites, for instance, that use a single URI and expect users to send POST requests to get back different pages." That's exactly what SOAP is all about.

I'm not sure I like the REST platform that much myself - BEEP or something similar seems like a better approach to dealing with these kinds of development issues. Despite that, I have to thank the REST folks for helping me express my persistent unease with Web Services more effectively. (And Keith Moore as well, whose RFC 3205 was a great start from a very different perspective.)