A day late, and a dollar short
It's all quite frustrating really.
« June 2004 | Main | August 2004 »
It's all quite frustrating really.
On merging and tracking changes:
On christening names:
On ancestral merges:
all from the Subversion docs
IronPython 0.6 for .NET/Mono is out. Jim Hugunin on the .NET CLR and his move to Microsoft:
[via Dong Zhang]
Tim Bray disagrees with Mark Pilgrim around URIs as identifiers.
Marks' position, which is fairly specific to Atom:
Tim's position, which strays beyond Atom:
On the face of things, this is very sensible advice, and is essentially the core W3C dogma - cool URIs don't change. But there are some details that happens to strengthen Mark's position and weaken Tim's. In short - forget about the application software; the Web/Internet infrastructure itself doesn't support cool URIs.
Tim:
Let's talk about ICANN instead. We can bang on all day about getting tooled up with decent software to generate sensible URIs and not harm Pagerank, but that is to neglect issues around domain name ownership, which cannot be solved in software. The dirty secret of the Web is that you don't own your domain name; you rent it. As soon as you stop renting it, every URI under that namespace is almost certainly toast, irrespective of whether someone else rents it after you. What kind of permanence is that? No-one will support your ex-URI space because it cost money to serve up content on the web and the more read you are (or were) the more it costs. No amount of non-broken software will not help you here. But an id tag can. Having said all that, here's my (strawman) counter-argument :
Arguing for permanance in http: URIs when the critical partition of the http: namespace, the domain, is de facto transient - make what you will of it.
I dislike Mark Pilgrim's position, because it involves managing the relationships between various identifiers, which can get complicated, is prone to inconsistencies, and is invariably a local solution (whereas using a lone URI is not). I think it helps to have to had to deal with or integrate namespaces where names/identities are composite entities like Atom's to appreciate what a compelling idea the lone URI is - folks, there's real money down in managing composite identities across administrations. Consequently the Atom id tag sucks. However, Mark's position does address issues with URI (ie, domain) transience. Consequently the Atom id tag sucks, but I will end up using it.
Emotionally, I like where Tim's coming from much better, but emotionally I like world peace much better too. Short of radically different web infrastructure and management, Mark's way will work out for most folks, who are not and never will be web geeks, administrators, or information architects. The "Cool URIs don't change" argument doesn't work so well unless you are in position to guarantee perpeptuity, or have a deep and strong technical understanding of web architecture - the evidence suggests it doesn't work at all at the "consumer grade", which is most bloggers. Otherwise - in my case that means roughly 150 euros a year (well worth it) and nobody trading on the name "dehora" coming to boot me out of that domain (we'll see about that being worth it). But it's my job to know about this stuff; I'm not a consumer grade exemplar.
I don't know - sometimes the cool URI view seems to belong in a Carlsberg advertisement, who don't do web architecture, but if they did it'd probably be the best web architecture in the world: power is decentralized to the edge peers, people own their domain names, they can affordably serve content, they can host their own content, they can continue to do so when the world loves to read their content, they can avail of sensibly crafted software so they don't have to be programmers if they don't want to be, they don't get hounded out the domains, bodies like ICANN and the IETF are running like well-oiled machines, and the physical architecture supports what the web and information architects want. The web we have is not like this - it is natted, centralized, dynamically assigned, firewalled, attacked, mismanaged, inefficient, litigated over, awash in expediency, filth, greed and infection. The Web is much more like the real world than the Web.
The deployed Web works against cool URIs, not for them. That's what Mark Pilgrim understands and the W3C does not. To publish cool URIs is to actively enage in a fight against entropy, the natural order of things.
Mark:
I don't have a problem using titles in Atom permalinks, or with using tag: URIs in Atom ids. I've come to decide that I won't change titles post publication. As for tag: URIs - I happen to be a fan of these. Despite whatever problems Tim has reading them, I find them easy enough to eyeball. It takes 15 minutes to implement a generator. The fact the scheme is not registered doesn't matter because the reason it's not is not a technical/engineering matter; it's down to an obtuse registration process. Again this is an issue that goes beyond software and comes down to management. So I say go ahead and use tag: URIs for Atom ids.
Despite all that I'm up for following Tim's line; I will continue dole out per annum to rent and host dehora.net for as long as I can afford it. I am careful about issuing permanent URIs, but definitely not careful enough - for example I've had to port most of the URIs for this weblog, since MT does not do out of the box what web 'nominalists' consider the right thing. I've left behind redirects as Mark describes above. The conclusion? As things stand it's unrealistic to expect more than a small minority to do likewise or to really care about stable identifiers. There are better things to be doing that agonizing over URIs and the lifespan of a domain name. That anyone has to is a failure of the architecture as deployed.
[limp bizkit: faith]
first published: 2004-05-29 17:05:33. Some edits have been made and typos fixed, but the reason that the date was changed (aka 'genxed') is that the ID/URI permathread has come up on the Atom working group list recently, and for anyone involved who reads here, this post captures my essential position on the matter, which is probably best understood as one of realpolitik.
DiveIntoPython DivesIntoPaper: "He's asking that we buy 4000 copies so he can pay back his advance - but Mark, you not familiar with the story of Dr. Faust?"
Does anyone know of comics (not just covers), drawn by Glenn Fabry other than the Slaine series?
Aside from Atom, where there was a long running discussion on XML + HTTP + RFC3023, I have some experience of this (along with Sean). In Ireland there exists an eGovernment integration messaging hub called the IAMS. The envelope format is XML but it's subsetted to be ASCII only on the wire - anything else is rejected. In truth this was done originally because one of the two first agencies on the hub insisted upon it, but the format has not been upgraded to allow higher encodings and in some part it is due to the current state of incoherence in application protocols between MIME and XML. Yes, borked encoding is a an issue, but not enough for us all to play Cassandra just yet.
I'm not as pessimistic about this, as I think this speaks to the rules not to interop - on the web the XML sky has not yet fallen in. And the rules are being looked at. Since Mark wrote (published? issued? created?*) his article, Paul Hoffman has informed the Atom WG that Apache will do the right thing with .atom files in a future release, Tim Bray has managed to persuade Microsoft to address the issue in a future release of IIS, and there is a new I-D obsoleting the Dread Pirate RFC3023 (specifically text/xml is gone). There is also a workaround that is acceptable in my mind and consistent with Postel's laws - decouple HTTP and XML processing altogether. At the end of the day the situation is restricted to encoding arcana, which is just one facet of the XML value-add and I suspect nothing like as substantial a part as Mark claims, which he has to in order to bolster the argument that XML has failed. The situation with XML on the web appears better than HTML, and imo that is the practical benchmark - things have never been better.
This does strike at one issue with the way the Internet and Web specifies its technologies - overall architectural consistency can get put on the long finger. Usually this is a good thing, but sometimes it leaves room for incoherence as formats and protocols are combined to new uses. And we will see another media types and applciation protocols problem like this in the future. Rather than encodings, it will be to do with the incoherence between media types and extensions to RDF semantics.
* Apologies - it's something of Atom joke
"...you have to learn how to work them - but boy, when you do, they make those languages start to feel like scripting languages." -Ward Cunningham.
I've just finished moving all my versioned stuff over to Subversion from CVS with cvs2svn.
R is an XML serialization for RDF.
Things R will not be supporting:
<r:rdf xmlns:r="http://www.dehora.net/r/2004/07/" version="20040718"> <r:graph> <r:description>I am not a description </r:description> <r:context uri="http://example.org/con10"/> <r:statement> <r:context uri="http://example.org/con12" /> <r:subject uri="http://example.org/10"/> <r:property uri="http://example.org/11"/> <r:value uri="http://example.org/12"/> </r:statement> <r:statement> <r:subject bnode="K12"/> <r:property uri="http://example.org/20"/> <r:value type="http://www.w3.org/2001/XMLSchema#integer">22</r:value> </r:statement> <r:statement> <r:subject uri="http://example.org/31"/> <r:property uri="http://example.org/32"/> <r:value>33</r:value> </r:statement> </r:graph> <r:graph> <r:statement> <r:context uri="http://example.org/con10"/> <r:subject uri="http://example.org/1000"/> <r:property uri="http://example.org/1001"/> <r:value>http://example.org/1002</r:value> </r:statement> <r:statement> <r:subject uri="http://example.org/one"/> <r:property uri="http://example.org/two"/> <r:value type="http://www.dehora.net/r/2004/07/type/xml" xmlns="" > <target name="get-ant-extensions" description=""> <get src="${ant.href.ext}/jdepend.jar" dest="${ant.lib.home}/jdepend.jar"/> </target> </r:value> </r:statement> </r:graph> <r:graph quoted="yes"> <r:description>I am not asserted, but I'm not sure what that means</r:description> <r:statement> <r:subject uri="http://example.org/1"/> <r:property uri="http://example.org/1/2"/> <r:value uri="http://example.org/1/2/3"/> </r:statement> </r:graph> </r:rdf>
It's a relatively flat, repeating structure, much like what you'd expect from database XML dumps or record oriented markup. An R document contains sequences of graph elements which in turn contain sequences of statements. A statement is the usual three part RDF structure.
<rdf
xmlns="http://www.dehora.net/r/2004/07/"
version="20040718">
<graph>
<statement>
<context uri="..." />
<subject uri="..."/>
<property uri="..."/>
<value uri="..."/>
</statement>
<statement>
<context uri="..." />
<subject bnode="..."/>
<property uri="..."/>
<value uri="..."/>
</statement>
<statement>
<subject uri="..."/>
<property uri="..."/>
<value>33</value>
</statement>
</graph>
</rdf>
The point of this however is that the document structure should be regular and clean enough to read and write - no striped syntax, no abbreviated forms, few surprises.
default namespace = "http://www.dehora.net/r/2004/07/"
start = rdf
rdf = element rdf {
attribute version { "20040718" },
quoted?,
graph*
}
graph = element graph { quoted?, description?, context?, statement* }
description = element description { text }
context = element context { uri }
statement = element statement { context?, (subject & property & value) }
subject = element subject { bnode | uri }
property = element property { uri }
value = valueURI | valueBNODE | valueTYP | valueTYPXML
valueURI = element value { uri }
valueBNODE = element value { bnode }
valueTYP = element value {
attribute type { xsd:anyURI }?,
text
}
valueTYPXML = element value {
attribute type { "http://www.dehora.net/r/2004/07/type/xml" },
ANY
}
ANY = element * {
(attribute * { text }
| text
| ANY)*
}
quoted = attribute quoted { "yes" | "no" }
uri = attribute uri { xsd:anyURI }
bnode = attribute bnode { xsd:NMTOKEN }
There's been no mail from the atom-syntax list in the last 90 minutes or so.
How odd.
A no-nonsense guide to Semantic Web specs for XML people - good piece by Stefano Mazzocchi. If you're new to RDF and OWL, but are comfortable with XML it comes highly recommended as Part I of a series. Some minor criticisms within.
But until RDQL hits the streets there is always OWL. Stefano nails it; OWL gives you something to do with your RDF. And OWL is a good piece of web tech - Recently on atom-syntax Mark Nottingham wrote out a list of things a versioning policy for Atom needed to be able to deal with. Previously the discussion had been focused mostly on SOAP style mustIgnore and mustUnderstand attribute usage and clear prose. Then Ian Davis produced a truly fascinating way of handling the version compatability requirements using OWL constructs, and one that deserves serious evaluation beyond Atom. At first glance it seems more powerful than the mU/mI approach Web Services developers will be familiar with.
* I have a tradition of putting that in red on this site, just so you wouldn't miss it.
** Hands up who thinks RDBMSes or SQL are not useful. Ok, now hands up who use an RDBMS because they like the Relational Data Model rather than SQL. Exactly.
Brian Foy thinks Blogs can be public databases:
Query language, anyone?
I've spent a goodly amount of time recently surveying client side technology. There's a number of things coming up personally, and professionally at Propylon that will involve UI work other than web interfaces. Generally we're adopting XUL/Mozilla at work, but I've been playing with Swing, WinForms, SWT, OpenOffice, WxPython over the last couple of months as well trying to nail down some choices.
And then two of my colleagues, Praveg and Tommy, pointed me at DB Designer 4. It's an open source database design and modelling tool targeted primarily at MySQL. DB Designer is a beautiful application - visually elegant, clean, responsive, consistent. It's intuitive - it mostly does what you expect it do. It also has a extremely good visual modelling space.
The last time I responded this positively to an application was probably IntelliJ IDEA or Mozilla mail. So given my current investigations, I had to go and get the source for this thing. And it's built on Delphi.
Which has served me a timely dope slap: it's the interface, stupid. Somewhere along the way I'd forgetten that toolkits come second to usability.
Jonathan Sobel: "Efficiency comes from elegant solutions, not optimized programs. Optimization is just a few correct-preserving transformations away."
Let's call it the "PHP Problem" (though the "LAMP Problem" would do as well). That is, Java and the JVM are not ideal for building applications which are fault tolerant, robust and will scale horizontally*. Threads, threadlocal storage, synchronization barriers, XA, classloaders and the security model are not the best mechanisms** we could have for building the apps we need to build, which are fault tolerant, robust and scale horizontally. The right mechanism is the Process. Pete Soper, one the folks working on Java Isolates calls the issues these mechanisms leave us with the "middleware blues":
Pete explains what Isolates bring to the table:
Isolates are slated for Java 1.6.
* Java != Jini
** I use the word 'mechanism' carefully; the right abstraction would be a service/resource
[sordid: amon tobin]
Russell Beattie on Friendster moving to PHP: "What parts of the Friendster decision am I missing?". Perhaps it's this. Java doesn't seem to be designed with multi-user environments in mind. LAMP solutions do.
[scissor sisters: laura]
You are viewing a mobilized version of this site...
View original page here