Re: unmarked linkend awareness by XML engines

At 9:44 AM 12/29/96, Terry Allen wrote:

Summary:
    1. Yes, I misread Terry. He clearly distinguished stating a policy from
enforcing it.

    2. [in great detail, point by point]: Neither a social contract for
defining such policies, nor a viable technical infrastructure for
supporting them currently exist. Therefore users who feel these needs must
fend for themselves. We should not standardize what is not known to be
useful, nor possible to be implemented

>Please reread carefully.  I can enforce in any number of ways outside
>of XML, but I must be able to state policy and be sure the user
>sees it before I can enforce anything.

Indeed, I did not read carefully. You clearly distinguished between
suggestion and enforcement, and agreed that at the moment the former is all
we can do. But I'm still going to argue against stating these policies,
absent any way to enforce them and agreement as to which policies are
correct. I do agree with Martin that we need a way to identify document
groups whose correct interpretation according to the author's intention
dictates that they should be processed together.

>| I also don't think that nuclear reactor documentation
>| with contractual display format requirements is primary in "SGML on the
>| Web".
>
>A very weak counterargument.
All I was attempting to do was to falsify a weak example of why we need
these policies, by pointing to the stated purpose of this group.

>Substitute the Walt Disney movie "Snow White".  Do you think
>Disney is going to allow someone to publish XML annotations to Snow White
>(conceivably not animated by family values) that can be overlaid on
>their intellectual property?  No, they're going to find a solution
>in which you can't see Snow White if you're adding on annotations.

This is their preprogative. We have no business, in my view, trying to
create new social mechanisms in advance of any workable social/legal
consensus on what is desirable. Never mind that we would be creating such
policies without a technical infrastructure to support them.

   Of course, personally, I consider such policies worthy of opposition
anyway...  But, if there were a set of mechanisms in use, and subject to
some widespread agreement, and support, then I would be forced to agree
that we should support them. But since neither accepted policies nor
workable mechanisms exist, I don't see why this is our problem.

>| Users of XML for such applications will be perfectly capable of
>| creating appropriate application conventions and DTDs to accomodate this
>| without our help.
>
>That doesn't square with what you wrote and I objected to:
>| >| No, we simply have to face the fact that end users are the only ones who
>| >| can decide what documents need to be in their processing set.
>
>So if XML users will be able to creat appropriate application conventions
>and DTDs, how?

People with contractual requirements will have to create their own software
that enforces them, and somehow ensure that only that software is used on
their data. This is not a change form the present state of affairs.

If support for such policies requires additional markup, it is easy to add.
For instance, the military (or some research organizations!) could add a
SECURITY="TOP-SECRET" attribute and ensure that their applications process
it correctly. But it's not _our_ problem, it's _their_ problem.


>| want to keep the ability to annotate -- regardless of the author's wishes,
>| and it should also be possible to publish those annotations, for those
>| readers who wish to view them. The author should neither be able to prevent
>| the creation or processing of such ilinks, nor a user, force others to see
>| them.
>
>See "Snow White."

If you don't want home taping of your show, don't sell the broadcast
rights. If you don't want satirical linking or guided tours of your data,
don't publish on the web. You decide what policies you require, and what
the economic tradeoffs of those policies are. Since I believe such policies
to be unenforceable given current technology (aside from possible custom
encryption applets, which we will certainly allow), I don't see that this
is an issue for this group.

>
>| This no-annotation
>| stuff strikes at the heart of what gives hypertext its great potential, in
>| my view.
>
>Others have different views, and they include large publishers
>who so far have not felt their intellectual property to be safe
>on the Web.

This doesn't bother me. If they can manage to develop open technology
through the IETF or W3C that supports them, then they can standardize an
application convention to support that, or add something to XML 2.0.

>|    Philosophy aside, we should pass no laws we cannot enforce, so
>| no-annotation policies are in the wastebasket, I think. And annotations are
>| so usefun and fundamental, that we cannot create any credible linking
>| system that does not enable their creation.
>
>Please reread careful to distinguish stating policy from enforcing
>policy, and recall the discussion of whether Sun could police
>its FPI name space.

I don't think that even stating a policy that is technically unenforceable
is good for anything except maybe generating lawsuits. I don't see why we
need to worry about this.

>That's not an acceptable state of affairs in the long run, is it?  If
>no improvements are made, publishers are likely to resort to methods of
>publication that (as now, in print) bind the intellectual property
>(in some binary unreadable format) to individual instances of applets
>that can be relied upon to enforce their display policies.  There's
>a whole software-protection industry just waiting to help them
>do it.

SHTTP or variants may address this. Like most security issues this is
mostly related to transport and authentication. I don't see that we need to
address this, especially since there is no infrastructure in place that we
can be called upon to support.

If we can't guarantee reliable transport (and we know this is the case) the
only place that a copyright notice can be guaranteed to be recieved is if
it occurs early in the byte-stream of a document. Any provider can
construct a DTD that enables this information to be included at the
beginning. No link can ever guarantee such security because the network
might break before the link can be followed but after the data is
downloaded.

Now I can imagine encryption scenarios that would solve this (copyright
notice contains a key to decypt the document body), but since they are not
deployed anywhere, I don't see whay we should worry about supporting them.
We don't prevent such things, just remain silent.

>I haven't been philosphizing, I've been stating the requirements of
>publishers who wish to protect their intellectual property.  You
>haven't offered anything in response except "you can't do that."
>Now, where in the XML architecture can I

If there's no effective way to acomplish an end, what is the point of
promulgating a bunch of rules and policies about that end. I don't
understand why we need to develop a new social structure and policy
language that is unenforceable for the forseeable future.

> 1) state my conditions-of-use policy?

 This is just not our problem. Persuade me that we can do even one useful
thing with this information, in the lines of guaranteeing that it is used.

> 2) indicate the bounds of my multimedia work?

Add an "external link" icon to some of your links. Define two types of link
in your DTD. Add a uniform header to all your documents. Add a copyright
notics to all your documents.

We do need a way to specify documents that should be processed together if
they are to be viewed as intended. For instance, Martin's separate link
file scenario should be accomodated properly, as default behavior.

>As the electricity has just failed, I leave it at that.

   Well, things are going dim around me too, but it's probably just too
much coffee...


   -- David

I am not a number. I am an undefined character.
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

Received on Sunday, 29 December 1996 16:01:32 UTC