" /> Bill de hÓra: April 2003 Archives

« March 2003 | Main | May 2003 »

April 22, 2003

Funniest blog thread ever?

Sam Ruby: Matrix reloaded

The funniest thing I've read in blogland for some time.

Chandler 0.1 shipped


April 19, 2003

Cog: cars as software

I saw the ad, Cog, for the first time this afternoon. I immediately thought - that's how a car made out of software would work.

There's no CGI trickery. Apparently it took 607 takes. So let's be honest - a car made out of software would really work like the first 606...

Bruce Schneier: Automated Denial-of-Service Attack Using the U.S. Post Office

Counterpane: Crypto-Gram: April 15, 2003

If you type the following search string into Google -- "request catalog name address city state zip" -- you'll get links to over 250,000 (the exact number varies) Web forms where you can type in your information and receive a catalog in the mail. Or, if you follow where this is going, you can type in the information of anyone you want. If you're a little bit clever with Perl (or any other scripting language), you can write a script that will automatically harvest the pages and fill in someone's information on all 250,000 forms.

April 18, 2003

Jboss: Making deployment less of a PITA

Anthony Eden: Deployment is a PITA

if you want to define a JMS queue you have to modify the file jbossmq-destinations-service.xml.

Instead of this, keep your own jms descriptor file in source control and deploy it onto JBoss along with the jar/ear. JBoss will pick up any file that ends in '-service.xml' in the default/deploy directory. Example:

<?xml version="1.0" encoding="UTF-8"?>
<!-- $Id$ -->
<mbean code="org.jboss.mq.server.jmx.Queue"
<depends optional-attribute-name="DestinationManager">
<depends optional-attribute-name="SecurityManager">
<attribute name="SecurityConf">
<role name="guest" read="true" write="true"/>

Granted this is not exactly well-documented (I took a good guess and it worked), but nothing in JBoss is.

Can we just expect JBoss to pick up our version of castor over the one that is in the lib directory? No. We must remove the one which is in the lib directory and copy our version into that directory.

There are two ways around this, both of which involve Ant. The first is to identify what jar you want gone and write some Ant to delete it as part of deployment. The second is better, but more work. Rewrite the the Jboss startup script in Ant. Yes, I've done this, yes, it works, and no I don't care about any possible weirdness in using Java to start Java. I did this to solve a nasty classpath problem. I extracted the classpth to a .properties file - much easier to work than a .bat file. After that I started up Tomcat with an Ant script, to see if it would work (yes) and just for fun, but now I think people should consider using Ant as the default mechanism for starting and stopping servers - and that means shipping JBoss et al with Ant files, not shell scripts.

It would be nice if there was some standard way of saying "execute this SQL code the first time this EAR is run".

Again Ant is our friend. Use a SQL task to run against the DB at deployment time. Although if JBoss used Ant, it could provide a system entity hook to do exactly what Anthony wants. It doesn't have to part of a J2EE deployment standard, just easy to do.

Later: from the comments, a good idea from Crowbar Tech:

...issuing arbitrary SQL when a bean is deployed. Simple create a trivial MBean that will execute any SQL passed via the configuring XML and include the according jboss-service.xml in the jar you deploy.

April 11, 2003

Running Java: I

First of a series on organizing projects and creating a good working environment for writing and managing Java code.


Install a JDK to c:/java or /usr/local/java. these will not be the default paths. If you have a jdk somewere else on your machine you want to use, make a note of where it is, but it's better if you uninstall it and start over.

Windows users: add these to your environment


Linux users: add these to your .profile

   JAVA_ROOT=/usr/local/java; export $JAVA_ROOT
JAVA_HOME=$JAVA_ROOT/jdk1.3.1_07; export $JAVA_HOME

Remember to change JAVA_HOME if you installed the JDK somewhere else - don't change JAVA_ROOT. We'll talk about how to set things up for multiple JDKs in a future installment.

ant and junit

Every Java project you work on will depend on these two - they are the most important java projects outside the JDK.

Unpack Ant 1.5.2 underneath $JAVA_ROOT. In windows add these envars to your environment:


In Linux add these envars to your .profile:

     ANT_HOME=$JAVA_ROOT/apache-ant-1.5.2; export $ANT_HOME
PATH=$PATH;$ANT_HOME/bin; export $PATH

Fire up a command prompt and type 'ant -version':

  > ant -version
Apache Ant version 1.5.2 compiled

Copy the following jarfiles into $ANT_HOME/lib - jdepend.jar, junit.jar, catalina-ant.jar, jing.jar

The jars are available at http://www.dehora.net/code/ant/ext . You can test your ant setup by downloading them with this buildfile:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<project name="ibs-third-party" default="get-ant-ext" basedir=".">
<property environment="env" />
<target name="get-ant-ext" description="" >
<property name="ant.loc" value="${env.ANT_HOME}/lib"/>
<property name="ant.href" value="http://www.dehora.net/code/ant/ext"/>
<get src="${ant.href}/jdepend.jar" dest="${ant.loc}/jdepend.jar"/>
<get src="${ant.href}/jing.jar" dest="${ant.loc}/jing.jar"/>
<get src="${ant.href}/junit.jar" dest="${ant.loc}/junit.jar"/>
<get src="${ant.href}/catalina-ant.jar" dest="${ant.loc}/catalina-ant.jar"/>

Notice already we are not dependent on the filesystem - this buildfile will work on ether Linux or Windows. Save the file somewhere as build.xml. Cd to that directory and type

 > ant

Unpack Junit3.8 underneath $JAVA_ROOT.

April 10, 2003

RAN: RSS for dependency management?

Sam Ruby: Experimental Gump RSS feed

Here's some ant to GET the Ant task extensions I tend to rely on:

   <property name="gob.href" value="http://www.dehora.net/code/gob"/>   
  <property name="gob.href.core" value="${gob.href}/core"/>
  <property name="ant.href" value="http://www.dehora.net/code/ant"/>   
  <property name="ant.href.ext" value="${gob.href}/ext"/>   
  <property name="ant.lib.home" value="env.ANT_HOME/lib"/>
  <property name="depend.where" value="${project.home}/${third.party.lib}"/>
  <target name="get-ant-extensions" description="" > 
      <get src="${ant.href.ext}/jdepend.jar" dest="${ant.lib.home}/jdepend.jar"/>
      <get src="${ant.href.ext}/jing.jar" dest="${ant.lib.home}/jing.jar"/>
      <get src="${ant.href.ext}/junit.jar" dest="${ant.lib.home}/junit.jar"/>
      <get src="${ant.href.ext}/catalina-ant.jar" dest="${ant.lib.home}/catalina-ant.jar"/>
      <!-- add more ant extensions  here -->

Great, I can get a jarfile. But seeing as people like Sam are pushing out RSS build feeds, why not push out release and version data as an RSS feed? Every OS project you depend on - you could examine its RSS feed to check for new versions, bugfixes, or just to find the link to download the jar you want. Even better each version could describe its dependencies in turn in the feed to create a dependency web (this seems handier than reegineering the Jar manifest file format). Then we could hack Jdepend to examine the graph.

I wonder how hard it would be to add <getrss/> to Ant that would understand such a feed?

Maven is a great code repository, but it has its own XML format you need Maven to understand it or roll your own. Exposing the Maven repository as RSS would be a good start as would getting to Ruper to fix on RSS as a data format.

Danny Ayers: Spotting disinformation

Raw Blog: Archives

Of Simulation and Dissimulation

April 09, 2003

Web services: Rosencrantz and Guildernstern are not dead

A popular view held by WS and MEST proponents is that for the purposes of message transmission (and typically SOAP messages), TCP and HTTP are equivalent. In other words layers 4 and 7 in the OSI model are no different in Webservices architecture (OSI layers 5 and 6, Session and Presentation we'll ignore, since the Internet does). This is argued as a good thing since we move the processing semantics into SOAP headers which will transcend the mere details of various transports.

I should point out that at the W3C at least, the ws-architecture group haven't feel informed by the OSI stack or the Internet subset and have a working definition of transport that is roughly 'everything that delivers SOAP messages'. Which is convenient, though it may be somewhat confusing to those involved in networking or anyone that did distributed systems 101 at college.

Before we start, some history. A mistake was made in the past with the once widely held view in distributed systems that location transparency was a good thing - you shouldn't care where an object is on the network. No number of systems and networking engineers waving copies Waldo and Emerson or protesting at the watercooler with the eight fallacies on placards was enough to presuade anyone who made decisions on this stuff that transparency was a bad idea. We had to build out systems and see them fail, just to be sure. We can argue that transport transparency is a similar error - highly desirable, but highly misleading.

So *is* there a useful difference? First, we need to be aware that 'application protocol' and 'transport protocol'are not well-defined sets, and what is meant can change depending on who you're talking to. On the other hand this is computing and programming, not science and mathematics; we don't always need or expect precise definitions to make sense to each other. But let's try to be more precise and identify a distinction - Actors.

The primary difference between application and transport protocols is that they differ in *intended effect*. The application protocols like FTP, SMTP and HTTP have the rudiments of what are known as "performatives". Now in computing terms, a performative is a highly formalized action word, or verb. 'Highly formalized' in turn means a computer program could make a decison on what to do based on the word along with some surrounding context (such as who said it and when it was said). You use a performative solely to influence another entity to do something on your behalf. The sent message in combination with the performative is designed to influence the sender. Compare that with the notion of a medium. A medium in this sense is that which carries the performative message.

Transport protocols aren't like this - they're not messenger boys, they're delivery boys. Transport protocols don't make the same utilization of action words. For example TCP use terms such as SYN, ACK, FIN, which are more like grunting than conversation. Claiming they're the same class of animal as application protocols is like claiming black is the same colour as white by progressing through infinite shades of grey; an interesting but crashingly trivial rhetorical trick.

So what makes application protocols distinct from transports (and much more useful and interesting) is that when you use an application protocol your are trying to get another system to do something for you by asking it. In English we do this with action words, or verbs. In application protocols we use action words too, but just a handful. HTTP has 8, but the vast majority of the web is getting things done with just three of them, 'get', 'post' and 'connect'.

In the world of computer protocols, application protocols deal with performatives and transports are media. The protocol neutral school of though would have us treat Internet protocols not as protocols, but as media.

Application protocols aren't the only things that use a controlled set of well defined action words. SQL is based around a few. Space or tuple based systems such as Javaspaces and Linda are based on action words. Most of the things you do with files and directories on your computer only require a few verbs (new, move, read, write, delete, copy).

In Internet protocols you can't just make up new actions words; they're usually a controlled set, and extended carefully. The main reason to add a new verb to an Internet protocol is to avoid corruption of the meaning of an existing one, but that's no guarantee of adoption by implementations. Much of thinking around making the most out of a few verbs is that it induces useful properties in a system, such as scalability and cheap global coordination. This would be very much part of REST doctrine, known there as the 'uniform interface'. Allowing anyone to make up new verbs seems like a good idea initially and may work for local or 'gated' cases (like a software component, an API or a chunk of object middleware), but imposes costs on all the other entities in the system to learn the new verbs and cross reference them with which objects they can be applied to. As the number of possible conversations increases the cost of communications quickly gets out hand and ceases to become sustainable. The counter-argument to uniformity is that no-one ever has to talk to everyone else, so the N-squared problem is theoretical. To which one could counter, no-one ever has to use all the possible 'transports' so SOAP transport transparency is in turn solving a theoretical problem (some study in how actual communications networks emerge and coalesce into hub and spoke models can be revealing here). The point of course is that the problems are not theoretical and that you do not have to reach asymptotic limit in either case to feel a pinch.

The main concerns of a WS architect, if we did accept a difference between transport and application, are two-fold. First that the architectural model for Web Services has a serious hole - SOAP does not run over all things equally. Second that the meaning of the SOAP message changes depending on the protocol it runs on, which is disturbing in a Heseinberg Uncertainty kind of way. If we have a payload with a FIPA-ACL 'inform' or getStockQuote stuffed into a SOAP envelope which is in turn stuffed into a HTTP envelope, we don't expect 'inform' or getStockQuote to mean different things depending on where it is. I don't think anyone wants this. Even hard core RESTafarians would probably agree there's value in being able to span systems with the meaning of SOAP headers intact. On the other hand it's not clear it's avoidable any more than probability is avoidable in subatomic physics. Most of the Internet application protocols that one might want to to run SOAP across involve actors in the roles of client and server who are communicating using performatives (or at least a version of perfomatives analogous to grunts and utterances).

Webservice and MEST architectures seems intent on modelling systems solely in terms of SOAP actors. There is little chance of giving up on protocol independence - it's too desirable a property. Fair enough. An application protocol changing the meaning of a payload is not a desirable outcome. But that is not to say there is no room for dissonance between the word games played at the SOAP level and what SOAP is being transmitted over. It's engaging in bogosity akin to that of location transparency to pretend that two SOAP actors having conversation 'Play' over UDP will be the same language game as the same SOAP actors having conversation 'Play' over HTTP, because the client and server actors in HTTP are there too, having their /own/ conversation and acting as middlemen.

Hamlet just isn't the same play without Rosencrantz and Guildernstern.

April 07, 2003

They just work

Zero hassle software - I don't recall any of these crashing:

  • IDEA (-1 from Adrian)

  • Winzip

  • Acrobat reader

  • TextPad

  • NTEmacs

  • Nero

  • Putty

  • Bash

  • PGP

  • SmartFTP

  • MoveableType

  • Google (thanks to Bo)

Junit reporting tool idea

Darren Hobbs: Stop dissing JUnit

Well said Darren. Here's my to-die-for Junit reporting tool (these are mock-ups at the moment):

all tests pass:


failed tests:


April 06, 2003

RSS2.0: a standard?

TheArchitect.co.uk - Jorgen Thelin's weblog: Distribution of RSS Version Usage - March 2003

De facto standards, I like it ;)

I re-examined the distribution of RSS version usage for my weblog, following a query on why I see RSS 2.0 as the "natural" version to base any "real RSS standard" on

Seems like Jorgen's also put a W3C XML Schema together for RSS2.0. I'm obliged to cook up a RELAX NG schema...

Greenpeace RSS feeds


RSS 1.0
RSS 0.91

They're updating every hour. The scraper script: gpr.py

It's pretty ugly. Greenpeace publishes XHTML, so there's room for improvement over regexen.

What's being scraped: Greenpeace news

[Amnesty feeds]

Amnesty RSS feeds

I mentioned recently that it would be nice for Amnesty to have an RSS feed.

Here we go:

RSS 1.0
RSS 0.91

They're updating every hour. The scraper script: air.py

What's being scraped: Amnesty news library

April 05, 2003

The apple of her father's eye

Russell Beattie Notebook - Alex is Sick

Russell's kid is sick and can't blow his nose. Here's a related child rearing war story. Don't try this at home :)

When she was a baby, my youngest, Dáire, had a very bad cold. Like Alex, she kept panicking about her breathing. So at one point she could barely breath at all. Screaming. Not nice. I had to do *something*.

I sucked the snot out of her nose. More than once.

Orla (my partner) comes home. I tell her what a wonderful father I'd been.

"That's nice, hon. You know you can buy snot-sucker things. They look like a turkey baster. "

"You can buy them??"

"Yes. I'll get one. Coffee?"

"Um, sure."

Why is Poorly Documented Code (the programmers fault)?

Weblogs Forum - Why is Poorly Documented Code the Industry Standard?

Perhaps because industry standard is to barely give programmers enough time to actually write the code itself :)

The first thing to do is figure out whether you have a lazy programmer or an overworked one. There will always be some jokers who don't/won't comment their work whether they have too much to do or not, but many programmers are up to their eyeballs in the quick and dirty. They're not burning out on overtime in order to write comments.

If you're developing an API, one way to be able to make time to document it is to design a smaller API. You can do this by using Plugins and Service Decorators.

One way to comment the code is not to use comments, but method names. A coment+statement can almost always be replaced with a method named after the comment containing the statement in its body. So instead of this idiom:

/* what */

use this one:

def what(){how;}

Cars and engines: Linux on the desktop

[ t e c h n o \ c u l t u r e ]

Most of the problems Karlin Lillington seems to have had with Linux is in installing it; that's fair enough, but the real question remains; is it usable?

It seems to be, if you're using Redhat or SuSe versions 8. And for what most people use computers for (email, browsing, office, messaging), the difference between OpenOffice+Mozilla+gaim and Explorer+MSOffice+AOLIM is about a year away from becoming irrelevant.

Here's the thing; my non-technical partner can use a Linux machine, but I wouldn't ask her to install it or even configure a desktop. These are two different aspects altogether - like cars and engines.

The single biggest problem with Linux isn't Linux at all - it's with web sites that won't work with Mozilla or Netscape, because the designers and engineers involved are only partially competent, or the business has decided to optimize the site for Explorer (and very probably Explorer 5+). This is fine in a work environment where you can dictate what runs on a desktop, it's somewhat shortsighted for a public site.

In the long run, it's just a matter of a Linux distributor getting deadly serious about going after Windows market share. It's bound to happen, after all there's only so many servers out there, and at some point in the next decade, Linux will saturate that market. Linux on the desktop will start inside firewalls and work its way out - some big companies and nations are already asking whether Linux on clients are a better economic option. You'd have to think that the only way Windows can stop being commoditized, in the way Linux/OS has commoditized the server market, is to optimize the servers for Windows clients to provide superior user experiences. Which is where .NET fits in.

And of course, the desktop is becoming a marginalized client - the future of high-volume low-cost software economics is in cheap laptops/wiretops and smaller mobile devices like phones. Microsoft still hasn't figured out a strategy for mobile devices, although it is now officially deadly serious about mobility - which means it's deadly serious about figuring out how not to have the Windows franchise lose out on the mobile market.

A Discussion with Alan Kay

O'Reilly Network: Daddy, Are We There Yet? A Discussion with Alan Kay


On Lisp

The greatest single programming language ever designed.

[update, sunday: I was wondering when Ted would blog this ; ) ]

On Java:

Java has a difficult time of adding to itself.

On polymorphism:

There is an interface algebra that today might be called polymorphism

On progress:

I thought we would be way beyond where we are now. I was dissatisfied with what we did there. The irony is that today it looks pretty good. The result of our work is techniques for doing software in an interesting and more powerful way. That was back in the seventies. People today aren't doing a lot of work to move programming to its next phase.

On computer literacy:

There just aren't any twentieth and twenty-first century toys to play with. Seymore Pappert's LOGO pioneered this and lead kids to real mathematical learning.

On our priorities:

Simplicity and beauty aren't high on people's requirement lists.

["Daddy, Are We There Yet?" The Computer Revolution Hasn't Happened Yet]

Brilliant piece on Google and weblogs

The Register

Frightening. Wait until The Man figures out how to game this medium.

Tim O'Reilly: REST vs. SOAP at Amazon

O'Reilly Network: REST vs. SOAP at Amazon [April 05, 2003]

I was recently talking with Jeff Barr, creator of syndic8 and now Amazon's chief web services evangelist. He let drop an interesting tidbit. Amazon has both SOAP and REST interfaces to their web services, and 85% of their usage is of the REST interface.

April 04, 2003

Mike Champion on SOAs

I think a case can be made that it's SOA because it's distributed, loosely coupled, standards-based, and can be conceived of as a "service" providing business value. It's not SOA if you use that term (as we sometimes do in these discussions) as a shorthand for "CORBA-like distributed object systems."

April 03, 2003

Messaging: Welcome to the 1970s

The Mountain of Worthless Information

Ted Neward gets messaging religion. Brilliant, I want to to review the book. Anyway...

A messaging-based system, by virtue of the fact that it intrinsically doesn't try to do request-response, tightly-coupled communication, allows for a tremendous flexibility in enterprise systems. RPC was created because messaging-oriented approaches were considered "too hard", owing to the loosely-typed nature of messages. But with Schema to provide strong-typing rules for XML payloads in SOAP, and with JMS using Java objects (which in turn must be strongly-typed) for Message payloads, this isn't as much of an issue anymore, and I'll argue removes much of the burden of working with messaging-driven systems. The inherent flexibility gained from a messaging-driven system, however, is something that no RPC-based system can ever match.

In my experience schema provide little value over an agreed upon XML document. Schema are good to check for a structurally sound document, but there's a bunch of other business level quiddities which require code or a rules language to enforce. This difference is that of a spell checker and peer review. At the moment information sharing using even the basic SOAP/XSD types is something of a black art. It's all highly fragile, and would be a lot worse if it wasn't for some seriously committed people.

Though if you are lucky enough to have Java across the enterprise, then using JMS and exposing SOAP doc/lit at the enterprise boundary is going to work well. But how many enterprises are truly homogenous like this?

When people first tried to run RPC and protocol tunneling over the web years ago, it was swiflty kicked out into CGI, not built into HTTP. And it seems no-body working on web architecture back then was paying much attention to this.

What finally cemented my relationship with messaging approaches, however, was the SOAP 1.2 spec. For those of you who haven't read the spec, you owe it to yourself to do so. Not because it's particularly fascinating reading, but because SOAP 1.2 is quite possibly the best thing to have hit the industry in a number of years.

SOAP is at heart an RPC technology with messaging retrofitted and boosted in the last eighteen months (that's being generous, it's only in the last six months people have stopped using getStockQuote to explain or justify SOAP).

Maybe this is my recent infatuation with workflow coming through (and workflow and messaging have such a deep relationship with one another that I suspect it's all one big love affair)

Don't go there. Build workflow on top of messaging. Munging the two together screws with dataflow and makes things too complicated. Rule of thumb taught to us via banking fulfilment systems - if you can't figure out how to automate a dataflow after a day or so, kick the flow out to manual processing. Messaging should be simple, clean, elegant; workflow is hard, dirty, bloody.

I can't imagine building an enterprise system of any large size without building on a messaging-based backbone. To do otherwise would just somehow seem to tie your hands too tightly.

Open secret: nobody in their right mind does anything other than messaging or flat data transfer for systems that are meant to be scalable and available. Every attempt to do otherwise has missed the target.

Get your messaging on:

ebXML 2.0

Semantic Web: crippled?

Re: SUO: Program Semantics

Bill Andersen:

The WWW community has taken this view to the limit, proposing a dizzying array of semantically crippled quick-fix languages and claiming to be doing "ontology".

John Sowa:

I certainly agree. They have ignored everything that has been done in AI for the past 40 years. The RDF notation, which was originally designed by R. V. Guha, who was formerly the associate director of Cyc, is a trivial subset of what Cyc was doing in 1984. Guha proposed the version 1.0 of RDF, and he hoped that a much richer language would be developed for version 1.1. But since then, the W3C has been hung up on pursuing such low-level details that Guha withdrew in disgust. He is still on the RDF committee list, but he hasn't participated in any of their work for over two years.

Meet the SUO. This comunity makes makes RDF look about as abstract as Perl.

April 02, 2003

Nice to have: www.amnesty.org/index/rss.xml

Amnesty International - Working To Protect Human Rights Worldwide

Amnesty doesn't have an RSS feed. But the news page looks structured enough to scrape.

Dublin blogger, 3 miles north

ideas asylum - Jamie's Weblog

Studies at MLE, worked on agentcities, interested in software agents. Tripleplusgood.

Alan Mather: Mobile Government

e-Government @large

There's a big opportunity for us to use mobile phones (which have something like an 80% penetration in the UK now) for quick notifications and alerts, "your house is in the flood plain and there's a big storm coming", "your passport is ready for collection" or "we're short of blood in the donor bank and you haven't given blood for 12 months, now's a great time" or something like that. There may even be the opportunity for a bit of dialogue, "you have a hospital appointment tomorrow at noon, can you still make it" coupled with a bit of to and fro to confirm the time. I've also talked in the past about some location based services like "the streetlight where I'm standing is out", "there's an abandoned car outside my house" and so on - simple to implement and, if done right, likely to attract traffic. Clearly, we're invading people's personal devices here - we're pushing content for probably the first time online - and that means we have to be careful about what we send, when we send it and what we do next.

Sourceforge login trick

I follow a good bit of code on sourceforge. For some reason I can never remember sourceforge's repository structure. Here's a quick fix for the bash shell:

dehora: 508$ cd projects/third-party/junit-addons/junit-addons
dehora: 509$ Repo=`cat CVS/Root`
dehora: 510$ cvs -d$Repo login
dehora: 511$ cvs -d$Repo update -P

For rw access:

dehora: 522$ cd projects/jas/project
dehora: 523$ Repo=`cat CVS/Root`
dehora: 524$ cvs z3 -d$Repo update -P

Don't know why I didn't think of that before.

April 01, 2003

CSV-ML: Comma Separated Value markup language

Comma Separated markup Language Specification

Should put an end to those permathreads as to whether CSV is equivalent to XML...

Free as in ?

Gerald Pfeifer - Building OpenOffice with GCJ?

Seems RMS wants to be able to build OpenOffice with gjc, but some Sun stuff is in the way. This has been picked up on dev@openoffice.org

The hardest problem II

ITworld.com - E-BUSINESS IN THE ENTERPRISE - A study in XML culture and evolution

Sean caused a bit of a stir with RDFers recently. And while this article doesn't deal with RDF, the identity and naming critiria he's critical of is at at the heart of RDF naming, much more so that the relational model. The nearest thing to Malinke naming in RDF would be bNodes (or whatever they're called at the moment).

Couldn't agree more about namespaces. What were they thinking?