Here’s something weird I noticed while fooling around with the Android SDK:
<?xml version="1.0" encoding="UTF-8"?>
<TextView xmlns:a="http://schemas.android.com/apk/res/android"
a:layout_width="fill_parent"
a:layout_height="wrap_content"
a:text="Hello World"
/>
If the weirdness doesn’t strike you, look twice.
(more…)
I noticed this morning that the main World of Warcraft site is indeed raw XML styled with XSLT. They’re serving straight XML directly to browsers. It appears to be mostly well-formed HTML (but not XHTML) wrapped up inside a custom page element.
I’m not quite sure why they’re doing this. It seems like an extra burden just for a different root element, but maybe the stylesheet does a little more. Hmm, looks like they’re using XSLT as a client-side templating language. Not bad. Saves them bandwidth and server-side processing I expect.
Interestingly the HTML includes some JavaScript. JavaScript inside XML didn’t used to work, even after a transformation to HTML. I’m guessing at least some browsers have gotten smarter about that.
Rails (and similar frameworks like Seam, Grails, etc.) work by inspecting database schemas and dynamically generating code at runtime. They implicitly assume a SQL database, which isn’t really a good fit for most publishing applications. Sure you can slice and dice documents enough to force them into tables, but it’s a lot like pounding screws into set concrete with hammers.
Many publishing applications, especially generic systems like Wikis, content management systems, and blog engines, would be better served by a native XML database and XQuery; e.g. eXist instead of MySQL. What would a Rails-like system look like in this environment? What would the conventions (instead of configurations) be?
(more…)
I was debugging some problems quoting a piece of a Google Doc article when I noticed something funny in their HTML source, an apparent string bogon. For example:
<pre> List<String><string> ls = ... ;<br/> Collections.sort(ls, new Comparator<String>() {<br/> public int compare(String s1, String s2) {<br/> return s1.length() - s2.length();<br/> }<br/> });<br/></string></pre>
In context, I think this is really a tag, not a badly escaped piece of the source document. A little googling didn’t find any information about it. I’m fairly sure this was never a real HTML tag or a browser extension, though I could have missed one somewhere. Can anyone shed some light on this?
(more…)
Despite some warts, XML and the Web have done pretty well. They work and they work well. A large part of that is because both were designed with certain basic principles in mind. This gives them a unifying vision and a clean architecture that solves many problems.
However, when a technology becomes successful it often attracts developers who recognize its success but don’t recognize or understand the underlying reasons for its success. Each one wants to make a change here, an addition there, a deletion somewhere else. Sometimes these suggestions are good and valid. Sometimes they’re not. However, even the suggestions that address real needs and use cases cause problems if they’re made without a deep understanding of the principles of the thing being changed. It’s like modifying a building by knocking down walls, cutting new windows, and erecting an extra bedroom on the roof. If you do this without consulting the original blueprints and understanding of the architectural principles that went into the house design, the best you can hope for is an ugly mess. More likely the whole structure will collapse around you, as the changes weaken the foundation the whole edifice rests upon.
Previous examples include cookies, frames, SOAP, YAML, SimpleXML, binary XML, RSS, and many other cases I could mention. However the latest is coming from a place I really didn’t expect it: the W3C XForms and XHTML working groups. These two are working together to eviscerate XML namespaces, and make it difficult to impossible to process XHTML2 and XForms with standard XML tools like XSLT and DOM.
(more…)
