Glacial Erratics

Transclusion v Blockquote

June 02, 2004

In a comment responding to Purple Placement Michael Day asks:    (862)

Would you agree that for quoting across different web sites, transclusion cannot replace blockquote?  T    (863)

That link is to a blog entry that addresses his thoughts more completely. Read that first if you want this to make any sense.    (864)

First, to correct a misconception in Michael's blog entry: PurpleNumbers were not originally created for assisting with TransClusion. That was something figured out later during the development of PurpleWiki 0.9. Their initial purpose was to provide an address for a paragraph or line.    (865)

I keep harping on TransClusion in this recent flurry of PurpleNumbers excitement because it was an unexpected consequence of purple numbers that has proven to be extremely useful. It also reinforces some important constraints on the identifiers used by purple numbers.    (866)

Michael has raised several points in his suggestion that blockquote be used instead of transclusion. I'll attempt to address each of them. Note that most of my comments speak both of the very limited implementation of TransClusion in PurpleWiki as well as the general notion (much more capable, in theory).    (867)

Transclusion is inefficent    (868)

A page doing transclusion of content from multiple servers will require multiple HTTP requests. This is certainly true. It's not unlike most web pages one visits today, where text is provided by one server, images by another, advertising from yet another. Michael's spartan site (which I like) is a notable exception.    (869)

I can't argue with blockquote being more efficient than transclusion, but you have to pay a price to get what transclusion is providing: live content that is up to date, expires less quickly (or sometimes not at all), and has the possibility of reference tracking.    (86A)

Transclusion is unreliable    (86B)

The web in general is unreliable and yes it can be quite irritating but there is no reason that the same measures used to cache full web pages could not be used to cache transclusions. A transcluding processor could even have the option of turning a transclusion that persistently fails into a stamp of the cached content, with an appropriate reference back to the dead site.    (86C)

The TransClusions in PurpleWiki are not this robust, but they are very much a prototype. A sort of demonstration to get people thinking, "oh this, is neat, let's learn from this and figure out how to do it right."    (86D)

Transclusion is dangerous    (86E)

I can't deny that there is a possibility that content loaded into a web page may not be the desired content. This happens with images now (which are a type of transclusion) and transclusions do, perhaps, enhance the possibility of trouble.    (86F)

There is also a danger when an entity publishes a link to offsite content: the content on the other side of that link may not be what is expected by the clicking user.    (86G)

But we're surviving. Coping. Well even.    (86H)

Transclusion is not expresive    (86I)

Can't dispute this one. It's true, if you transclude a chunk of something, it is the case that you can't change it. This is both bad and good. Bad because you can't emphasize or edit the content. Good because you can't edit the conent. There's a political juggling of who gets to control the content with Transclusion. It goes both ways with the winner not being clear at all.    (86J)

Transclusion belongs behind the scenes    (86S)

Here Michael argues that Transclusion should be kept in CMS, technical documents, knowledge-bases, wikis, whiteboards and other groupware. It's true that this is where I use it most, but that is only because those are the only place where I can use it. I would love to be able to transclude between blogs and wikis anywhere on the planet[1]. Why should closed-world systems have all the fun?    (86L)

If transclusions encourage productive collaboration in closed world systems, the benefits expand in open-worlds where the level of commentary and distribution of ideas vastly increases. That's the overarching goal: expanding commentary and distribution.    (86M)

Can the current architecture of the web support such things in a highly efficient, robust and secure way? Maybe not, but tools and people can evolve.    (86N)

(I feel to some degree that I've been provided a slow pitch or set up by Michael; or is it that there are just large differences in world view?)    (86O)

[1] There are designs and prototypes in PurpleWiki that support:    (86P)

Sending...