Re: Transclusion

Tim Bray writes:
| At 10:15 AM 12/21/96 -0800, Terry Allen wrote:
| >>Hell, I want general transclusion a la Xanadu...
| >which is another linking behaviour that the Web already has...
| >IMG was bad enough (from this angle); FRAMEs are dreadful...
| 
| Don't want to be pedantic, but this after all is a discussion of hypermedia
| so we should get our terms straight.  I *think* transclusion means inclusion, 
| not just of another document, but of an arbitrary segment of another document, 
| in Nelson's scheme all done by byte offset, but the key point is you're 
| pulling in a piece of something else.  I think what the web does now with 
| <img> and <frame> is inclusion rather than transclusion.

Fair enough.  IMG could be thought of as tranclusion-in-whole.  FRAMEs
make the META information invisible (in Navigator's view of document
properties), so might qualify as transclusion of a part.  Either way,
byte-offset transclusion is on its way both for HTML (there's a
URL scheme proposed for it) and something similar will apparently
be in XML (it's one of the desiderata).

Whether inclusion or transclusion, it's one of the existing link
behaviors ("include and interpret", e.g., render that GIF).  Another 
is what happens with SCRIPT:  "include and execute" (which is a
little different from "include and interpret", perhaps).

| 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.

Having made that point, I don't want to clutter this list with further
discussion of it.  I respond below to Keith Corbett, but if anyone
else wants to follow up, let's take the matter offline.

Keith writes:

| Terry, are you also opposed to server cache? The publisher is only informed
| of the first hit on his server.

Under some circumstances, yes.  For example, I use HTTP-EQUIV to time
out my book catalogue pages after a week.  And separately, there's
quite a bit of thinking going into how to arrange matters so that
the publisher can obtain info about subsequent hits via HTTP.

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.

| I doubt that even a perfect extensible markup language would contribute
| much toward solving the problems you've raised.  The underlying conflicts
| are social and economic, not technical.

I am not pushing for a solution in XML, only bringing up the issue.
I think the problem is precisely a technical one.  It may well be that
solutions should be sought outside of XML, but a technical solution
will eventually be found.  The publishers of music and movies will
see to that.  

| When a document crosses the line from content into user interface it's no
| longer information or speech, it's a program to drive a data processing
| terminal. That means, among other things, that all bits on open display are
| basically up for grabs.  Open protocols facilitate stealing, closed ones
| facilitate hoarding. From this angle, IMG and FRAME are no more problematic
| than http GET.  When http is illegal, only criminals will transport
| hypertext. 

I don't see XML, HTML, or SGML as user interface, but as content
that is interpreted by a data processing terminal, as you put it.

Recall what Jon said about the outcome would be of misusing Sun's 
owner identifier:  if they catch you they'll sue you (my words).  I 
may be able to keep unauthorized use to a level I find
acceptable by taking the same approach.  That is, it may be sufficient 
for my needs to simply be able to know what is going on and to say what 
conditions attach to use of my intellectual property.  I can't do
that now.

| New client/server protocols with micropayments might provide better
| incentives for publishers to remain open. Your publisher wants to publish a
| price list on their Web site and to enforce contracts expressed and
| implied; their clients want to preview the data and to negotiate through
| brokers on price and features and to enforce warranties on performance.
| They're going to want a refund when they don't get what they asked for.
| Semantic markup may help here, if publishers can point to a page and say
| "see it said right there we were *selling* the last page of the mystery
| novel". But that kind of thing will be as popular as shrinkwrapped license
| agreements and the fine print on car ads. 
| Online page charges won't catch on unless the system is ubiquitous, easy,
| cheap, and enforcible. Combining commerce with high bandwidth may bring
| per-transaction costs down far enough to reduce the incentives for clients
| to "cheat".  The newspaper distribution model may be the one to watch. When
| you're selling thousands of copies at 50c and leaving bundles out on the
| street you don't worry overmuch about people who clip articles and tack 'em
| up on their cubicle walls. The real money is in VOLUME. 

Yeah, forget micropayments.  But I'm not talking about any specific
business model or payment regime.  The problem extends even to documents
freely available to all comers:  I don't want pieces of my (free) online
books quoted without attribution, plagiarized, or enframed in context
that misleads the reader wrt the rest of what I wrote.  (And so I find
most proposals for annotation schemes to be problematic.)

I want something like the ability to say formally that transclusion may 
be performed only for fair use or pursuant to special agreement, and that 
transclusion must be signalled by the link type "get-for-transclusion" 
(whether that's communicated in HTTP or a URL or XML or some other way).  
Then I can refuse to serve in response to such requests (fair users can
transcribe the content and have no need to transclude, at least if
it's static), and have reason to sue if my intellectual property was linked 
to for transclusion without use of the appropriate link type.  There are 
presumably scads of other ways to get something like the same result.

| Hmm, that's where we came in with SGML.  If we can get the lawyers and bean
| counters interested there may be some role for XML ... maybe combining AI
| and ecash ... I'm picturing some weird hybrid with DSSSL + agents + JEPI +
| EDI  ...

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. 


Regards,
    Terry Allen    Fujitsu Software Corp.    tallen@fsc.fujitsu.com
"In going on with these experiments, how many pretty systems do we build,
 which we soon find outselves obliged to destroy?" - Benjamin Franklin
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

Received on Saturday, 21 December 1996 16:47:23 UTC