I’ve talked about my
nose for self-description problems
before in the context of RDF and media types. Now, with the
publication of -04 of the
RDF/XML media type registration draft,
there’s another one.
Comment submitted.
The best summation of the issue, as I
wrote
in the ensuing
thread is probably;
If somebody on the Web can’t distinguish between an RDF message which
says “Mark hates bananas” versus one that says “Mark hates bananas (but
not really)” (aka unasserted), then there is a failure to communicate.
The “but not really” part must be part of the message. It can either be
done through mechanisms in the RDF specs themselves (e.g.
parseType=”literal”), or it can be done in an encapsulating spec or
registry, such as the media type registration.
Joshua writes;
Mark Baker is asking for Orkut + De.licio.us. I would actually rather see FOAF + de.licio.us, and better integration with the browser.
Ah, yes, definitely. But I’d also like a decent interface to the FOAF Web.
So I what I really want is …
- Orkut, Friendster, Linked-In etc.. to be value-added aggregators of FOAF (and other, e.g. bookmark) data
- All of those, and others, to compete based on who presents the better interface to that data
rather than who “owns” it
I’m not sure what kind of browser integration would be needed, beyond something generic like
mod-pubsub. Certainly an RDF viewer. But in general
I like to avoid application-specific (e.g. FOAF) functionality in the browser, because that
doesn’t scale. But
there are exceptions (which bookmarklets are perfect for). And perhaps there’s even a way to
generalize what Joshua wants from browser integration, but I can’t say because he doesn’t describe
what he has in mind.
If Atom is going to
consider merging
with RSS, it should merge with RSS 1.0.
I consider it a mistake that this wasn’t
done in the first place,
primarily as a means to hook into the installed base of RSS 1.0 processors, but also
to gain the self-descriptive extensible goodness of RDF.
It seems the
Web Service Description WG
has
opted
not to bother trying to fix a glaring architectural flaw in Web
services by maintaining the status quo of making it impossible to determine
which operation is being requested for any particular (or even a reasonably
sized subset of) SOAP messages. Bah.
The issue behind this problem is that the so-called “document exchange” model used
by Web services is little more than wishful thinking; If only we hid the operation
from the message, then we’d be more loosely coupled, yeah, that’s the ticket!.
Sorry folks, it just don’t work like that. What you’ve done by removing the operation
is just to make your message less self-descriptive. That’s it. The only
gain is saving a few bytes.
If there’s anything worse than RPC, it’s less self-descriptive RPC.
The easiest way that we know to go about “doing away with operations”, is to
just give every component the same set of operations. Then you don’t really need
to think about them much of the time.
you agree with Chris Ferris? 8-)
(though I still wish he’d stop referring to HTTP as a “transport protocol”)
I subscribed to public-webarch-comments
because I like to hear what folks have to say about the
AWWW document.
Since Saturday afternoon, the comments list has been absolutely
bombarded
by spam (to the tune of about 600 messages). It’s like it’s become the Internet’s sweetest
honeypot, despite
presumably having a handful of subscribers. Spammers work in mysterious ways.
Luckily my new still-being-trained spam filter
caught all of them after I trained it on the first one, but still, yikes.
over 900 messages as of late Sunday. Had to unsubscribe to lessen the
load on my little P133 gateway box.
Jim Webber joins the fray. Welcome, Jim. Subscribed
(sorta – hurry up with the RSS and permalinks! 8-O )
One of his first entries is titled “Messages != Flattened Objects”, which is a topic
very near and dear to my heart, and a frequent point of discussion between Jim and
myself, both
publically
and privately.
The term “Flattened Object” is interesting. I hadn’t heard it before, though
I do use
“serialized”
and
“pickled”
on occasion. This is what I call a
“document”; a bag of bits REpresenting the STate of some object.
Yet another WS-*
specification
with a bunch of Get* methods that fails to use the SOAP 1.2
WebMethod feature
which supports HTTP GET and therefore giving important resources URIs.
WS-* effect considered harmful? It appears so.
In my ample spare time, I often fire up one of a handful of multiplayer first-person
shooters that I’m familiar with, and play against opponents across the Internet.
Perhaps you’ve done this too.
I frequently use a tool called
Gamespy3D to help me locate the servers
playing the game/mod/map I’m interested in. Of course, sometimes pinging this list
of servers takes quite some time, leaving the ever-growing possibility that the
ones pinged first are no longer playing the map they said they were N seconds ago.
As a result of this, sometimes I double-click on a server, only to end up playing
a different map than I intended, wasting up to a minute of my time.
What would be nice is if part of the “join” message that is sent from
my PC to the server, contained information which declared “Here is the map I’m
interested in playing, and if you’re not playing it right now, I don’t want to join”.
Of course, sometimes you don’t have the expectation that any particular map is
being played, such as when you just want to join one where you know your friends
hang out. So it should be optional. But when present, its value must be understood.
You know, something like
SOAPAction (well, mostly),
something that forms languages should
support, because
that server list inside Gamespy is a form.