Re: Transclusion

Terry Allen writes:
   | <img> and <frame> is inclusion rather than transclusion.
[...]
   Whether inclusion or transclusion, it's one of the existing link
   behaviors ("include and interpret", e.g., render that GIF).  Another 

To my earlier list of additional linking facilities should be added
"involuntary occlusion" (the auto-replacement of one page with the
next, using the well-known tricks with push and pull). "Include and
interpret" is a little different from "replace and interpret" :-)

   | All this is orthogonal to Terry's point that silently including someone
   | else's stuff raises some difficult and important issues in the area
   | of intellectual property rights.

At least at the moment it is largely detectable, in that an IMG or a
whole HTML document-in-a-frame is visible as an identificable object
(usually; discounting IMGs which are text coincidentally set in the
user's default typeface).

Silent inclusion of text fragments from another document in such a way
as to be seamless to the reader, is a more problematic facility. I've
no doubt many millions of people would like it, though.

   But in general, I know there is a problem, and that its basis is in 
   part that the publisher has no way of even communicating terms of use 
   and conditions of sale, much less of negotiating on them.  Without
   such facilities enforcement of copyright is pretty hard.

We had such a proposal, if my memory serves me right, on html-wg(?) a
long time ago. It involved a #REQUIREd PERMIT attribute, whose value
was a formatted CDATA string which could be chopped up into date,
owner, ISBN, and a few other bits, and slotted into a standard
copyright para, which would pop up over the center of the object and
had to be cleared with an explicit click from the user.  I think it
was dismissed on the grounds that it predicated client behaviour :-)

   You could encrypt your content and wrap it in a Java applet that 
   displays it only in its own window, refusing to cooperate with other
   display agents.  That's what the music and movie people will prefer,
   I suspect, and that *is* a user interface solution.  

   But there has to be a better way.  If we stumble across it in the course 
   of XML link specification, wonderful.  If not, well, that's okay. 

Copyright usually has some legal force behind it somwehere. Used to be
printing and publishing was too expensive for widespread largescale
amateur breaches. But there's nothing yet to prevent Joe or Jill
Codehack writing a browser that defeats our best intentions at
policing links, and making it available. 

Conclusion: we need to bear it in mind, but it's not our job in
writing XML to implement the politicians' or lawyers' work for them.
Just to point out what they have to do. 

///Peter

Received on Saturday, 21 December 1996 19:18:30 UTC