Das eez kaput! Sometime around 2002 I spaced the entire database table that mapped individual entries to categories. Such is life. What follows is a random sampling of entries that were associated with the category. Over time, the entries will be updated and then it will be even more confusing. Wander around, though, it's still a fun way to find stuff.
So a close examination of Canadas past can disclose both a strong foundation in the ethic of tolerance and inclusion, as well as the dark side of group belonging in the form of intolerant treatment. I want to explore both of these aspects of our heritage, in the hopes of ultimately demonstrating that, as Canada has matured and grown as a nation, we have embraced and cultivated the first of these traditions in order to do a better job of confronting the second we have learned to value and institutionalize the ethic of respect for difference as a means of combating exclusionary thinking.
#20030810-pnd {
background-image:url( span#20030810-pnd + span.caption > a[href] );
}
asc says: "By examining the psychodynamic effects on human cognition of the adoption of the technology of writing we can logically assess and contextualize the potential effect of the massification of networked information systems on our day-to-day thought processes. The identification of congruent, parallel and differential affect between writing and network technologies demands that their development be considered above and beyond the dictates and imperatives of consumer capitalism, it demands that the Internet be thought of in terms of public infrastructure rather than saleable capital." asc says: Dude, where's my car? bendoh says: did a lawyer write that? bendoh says: He should have put a smiley face at the end of that. It would've made it all better. asc says: Academic. asc says: Lawyers would almost certainly argue in favour of saleable captial because then it would subject to all kinds of litigation. bendoh says: I would not want to read that paper. It would make my head fall off and subsequently explode. asc says: That would be a symptom of massification and the differential aspect of the network. bendoh says: If I could think of anything remotely witty to respond to that with, I would say it. asc says: Dude, where's my car? bendoh says: hehe
Bagatelle \Bag`a*telle"\, n. [F., fr. It. bagatella; cf. Prov. It. bagata trifle, OF. bague, Pr. bagua, bundle. See {Bag}, n.] 1. A trifle; a thing of no importance. Rich trifles, serious bagatelles. --Prior. 2. A game played on an oblong board, having, at one end, cups or arches into or through which balls are to be driven by a rod held in the hand of the player. web1913
bagatelle n 1: a light piece of music for piano 2: something of little value or significance [syn: {fluff}, {frippery}, {frivolity}] 3: (British) a table game in which short cues are used to knock balls into holes that are guarded by wooden pegs; penalties are incurred if the pegs are knocked over [syn: {bar billiards}] wn
Similar to "indeed" but used in a posh accent. Pronounced in-dig-narta.
ex. "Have you had enough caviar, Giles?" "Indignate, I have, Samuel."
response
method for the search widget.
Mellifluous \Mel*lif"lu*ous\, a. [L. mellifluus; mel, mellis, honey (akin to Gr. ?, Goth. milip) + fluere to flow. See {Mildew}, {Fluent}, and cf. {Marmalade}.] Flowing as with honey; smooth; flowing sweetly or smoothly; as, a mellifluous voice. -- {Mel*lif"lu*ous*ly}, adv. web1913
mellifluous adj : pleasing to the ear; "the dulcet tones of the cello" [syn: {dulcet}, {honeyed}, {mellisonant}, {sweet}] wn
Beyond big.
ex. The rock star was making hypernormous amounts of money.
description
element in RSS. Wouldn't it be nice to have a markup language that you
could add structure and logic to? To which arbitrary tags could be
applied and that still "just worked" when the document proper is sent
to a browser. Even if the backend magic suddenly broke, the site might
look like crap but presumably it would still be usuable. HTML is, we'll
all agree, not the best candidate at first blush. XHTML, on the other
hand, comes pretty close. Through the magic of parameter entities and
the ability to define and tweak them
inside
the
DOCTYPE
declaration, you can essentially wrap (X)HTML in your own case-specific
tags.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" [ <!ENTITY % dtdMods SYSTEM "http://www.eatdrinkfeelgood.org/dtd.mod"> %dtdMods; ]>This is still an imperfect solution. The first problem is that the browsers have never been taught to deal with this syntax so the
%dtdMods;]>
from the DOCTYPE declaration gets printed to the browser window. Dunno.
The second problem involves the fact that I am overriding the
%Block;
entity, in
dtd.mod
, which is used to
determine
the child elements for the
body
tag. The good news is that I can re-assign the list of valid children,
in this case :
abstract
;
section
;
include
, thus applying more structure to my document than a pure formatting
language allows out of the box. Since the children of the first two
elements are
p
and
div
, respectively, I can start tapping away in HTML to my heart's content.
The bad news is that the
%Block;
entity is also used by the
blockquote
and
noscript
tags. There isn't much to do about this since you can't redefine
elements; oh well. A third problem is that you can not use already
defined parameter entities inside new definitions...
<!ENTITY % foo "(a|b|%c;|d)*">...without causing the w3c validator grief. I don't know why. Rudimentary testing suggests that you should not waste your time trying to assign styles to your new tags. Your mileage may vary.
<xsl:select value-of = "document($uri)/more/xpath/to/*[@id=$id]" > <!-- do stuff here --> </xsl:select>...so that all you'd need to do an otlml-blog are two stylesheets. The first slurps all the nodes -- note that
$uri
could just as easily live on a local fileshare as on the network -- and
builds a new document. The second transforms it into whatever format is
being requested. The problem with this scenario is that it's not very
smart about caching changes and will trot out across the network to
slurp each embedded document, regardless of changes, for every single
request. Thinking out loud now: you could enable the necessary feeping
creaturitis on the user end to send a
Hey, I've changed
notice, akin to the UserLand <cloud> thingy. Those changes
could be written to the server and read by the XSLT processor which
could be taught to return a cache file... but that still has problems
since you're can't cache the individual nodes themselves from inside
the first stylesheet. Anyway, you get the idea. Meanwhile, Dries
writes:
See http://www.drop.org/node.php?id=752 . We had this thread/discussion (see link above) about template systems, and the use of XSL/XSTL when generating dynamic pages. Most of the others tend to favor Smarty, FastTemplate and similar template systems, yet I think XSL/XSTL (or after reading your blog maybe OTLML) might be the way to go.The issue, ultimately, revolves around the place where your security, performance and logic requirements meet. I have never been a fan of embedding code in markup. Partly for maintainability, partly for security. But XSLT, like HTML and RSS before it, is a funny beast being used "out of context", as some people in the thread have pointed out. While the built-in logic can be maddenly insufficient, XSLT also has enough power that a malicious or stupid programming error can bring your machine to its knees. So, if you're working in an environment where there are designers and developers and never the two shall meet (they should, but that's another story) you shouldn't fob off the writing of the stylesheets on the designers any more than you would the writing of embedded/evaluated Perl code. For a long time, I was a purist about templates, arguing that the only artificial construct they should contain are substitution variables. Which meant a lot of fucking templates, especially if you were doing tables. Lately, I've been coming around a bit. The ability to pass a data structure other than a scalar and have the tools to read them (minimal conditionals and looping) in place is nice. I'm still not convinced, though. Speaking of emebedded Perl code, I wonder how difficult it would be to write a Template::Toolkit module to build a "smart" OTLML guest/group blog rendering tool...
dude, where's my car
This document uses CSS kung-fu and a small amount of JavaScript for rendering its contents. Efforts have been made to separate the form from the content so if you are viewing this in a text-based browser it shouldn't be an issue.
On the other hand it may look funny if you are viewing it in a browser with incomplete CSS and/or JavaScript implementations. Internet Explorer 6 comes to mind.
It's not that I don't love you. However, my time is limited and I no longer feel very good about spending it working around any one browser's inconsistencies with little, or no, confidence that they will ever be fixed or otherwise made more inconsistent at some later date.
On the other hand, if something is down-right unreadable please let me know and I will endeavour to fix it.
yes, we have no bananas
This page may not validate. It's not that I don't care, it's just that I'm not aware of it yet. Part of the reason that I rewrote the entire back-end for managing this site is that the old stuff made it too easy for these kinds of mistakes to slip through the cracks.
See also : W3C::LogValidator.pm
it's the software, stupid
