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)

Comments

1/5
On June 2, 2004 08:53 AM Michael Day said:

Hi Chris,    (870)

Thanks for the very informative response! Since I haven't done much with transclusion myself, I appreciate hearing more about the topic from someone who actually uses it.    (871)

I also appreciate the irony of your linking to exact locations in my post via PurpleSlurple, given the topic we are discussing! That's very clever, and it also reinforces a point I made earlier, that adding purple numbers is unnecessary in the presence of good linking tools.    (872)

Something I am interested in is applying this kind of linking technology to annotation, which I believe does not suffer from the problems that transclusion does. But perhaps more debate of those problems and their potential seriousness is worth considering first.    (873)

2/5
On June 2, 2004 09:16 AM Michael Day said:

I think ultimately we are seeing the same problems, but we have different viewpoints on the potential benefits that transclusion can bring. You say:    (874)

"I would love to be able to transclude between blogs and wikis anywhere on the planet"    (875)

And I say, why? What does this bring you that blockquote does not, given that blogs at least are rarely updated once posted? (And if they are updated, other bloggers may still wish to quote the original, if it is the topic of some debate for example).    (876)

Transcluding parts of an article from Wikipedia might make more sense, but even then it seems more like a closed-system rather than a web scale ability.    (877)

I assume that the most compelling use cases for transclusion would involve transcluding dynamic content, that will *not* stay the same and hence must be refreshed from the source at regular intervals. But I have not seen many such use cases proposed when transclusion is discussed.    (878)

3/5
On June 2, 2004 11:52 AM Michael Day said:

I have posted some thoughts about how transclusion compares against annotation    (879)

4/5
On June 2, 2004 04:20 PM Chris Dent said:

And I say, why? What does this bring you that blockquote does not, given that blogs at least are rarely updated once posted? (And if they are updated, other bloggers may still wish to quote the original, if it is the topic of some debate for example).  T    (87A)

Is choice a compellling answer here? I think so. I'm glad I have the choice to transclude rather than quote.    (87B)

It's also an ease of use issue. Since you've not had the chance to play with this stuff in the way that I have, we have much different exeperiences of its utility.    (87C)

I assume that the most compelling use cases for transclusion would involve transcluding dynamic content, that will *not* stay the same and hence must be refreshed from the source at regular intervals. But I have not seen many such use cases proposed when transclusion is discussed.  T    (87D)

I thought this too, and while I still think it is a very good idea, I've used it only rarely. These days the primary utility is that it makes it easy for me to do things I want to do. Such as include the text from your comment. I could have cut and paste bet then I wouldn't have the automatic link back to your full comment.    (87E)

In this case, since we're all on the same page, it's a bit of overkill, but there are many situations where we are not on the same page.    (87F)

I invite you to visit my wiki where you can try some TransClusion, or perhaps visit PlaNetwork:InternetRelayChat where it is possible to transclude into a live IRC channel from its logs or associated wiki.    (87G)

This is not some kind of change the entire face of the earth in one day kind of thing. It is a simple adjustment in how you can handle information that some people have found very useful.    (87H)

5/5
On June 2, 2004 07:29 PM Eugene Eric Kim said:

Regarding:    (87L)

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.  T    (87M)

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.  T    (87N)

While transclusions were not the reason for PurpleNumbers, they were certainly a reason for PurpleNumbers. It was not an unexpected consequence at all. PurpleNumbers were a first, critical step in bootstrapping the features of Augment and Xanadu onto the Web. Transclusions were certainly one of those features in mind. I insist on correcting the record here, because I had to face the wrath of TedNelson on numerous occasions for -- in his mind -- misinterpreting what transclusions are. I've got to get some credit for my pain. :-)    (87O)

Actually, several people deserve that credit -- LeeIverson?, JackPark, EricArmstrong?. Which brings me to my next point: If you recall, you and I had several conversations about nodal repositories very early in our discussions regarding PurpleWiki (which followed naturally from the earlier discussions I had had with Lee, Jack, and Eric). One of the reasons for having a nodal repository was to enable transclusions.    (87P)

What was unexpected was that your screen-scraping hack worked just fine -- no nodal repository necessary. What was also unexpected was how much pleasure I got from seeing a real-live transclusion. It was one of those things where you know you want it, but you don't really realize how great it is until you actually get it. (Which is far better than knowing you want something, then being let down when you get it.)    (87Q)

Sending...