W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > December 1996

Re: unmarked linkend awareness by XML engines

From: Terry Allen <tallen@fsc.fujitsu.com>
Date: Sun, 29 Dec 1996 09:44:15 -0800 (PST)
Message-Id: <199612291744.JAA16184@ishtar.fsc.fujitsu.com>
To: dgd@cs.bu.edu, w3c-sgml-wg@www10.w3.org
>David Durand writes in response to me:
| >| 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. We can't
| >
| >No.  As an author and publisher I must be able to indicate *my*
| >view of what that set of documents is, and, of the links in the set,
| >what are relevant to my author-primary view of my own intellectual
| >property.  I must also be able to assert (not enforce) via my
| >markup that this view is mandatory (if it is).  Consider the case
| >of nuclear reactor documentation in XML governed by an effectivity
| >policy before you assert that the end user must be king.  Mechanisms
| >of policy enforcement need not be specified (because enforcement
| >is a function of applications), but the assertion that there is a
| >policy must be supported (because linked metadata is the obvious
| >way to support it).
| 
|    "Indicating" is one thing, but enforcement is another. I suggested that
| such indications would be useful, but that is different from requiring that
| those indications must be followed by anyone. Enforcement is pointless,
| because intentionally non-conformant clients can violate any such
| restriction anyway. 

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.

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

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.

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

|     I'm not opposed to being able to suggest to an application what it
| should do, just the pretense that it can be required. Most particularly, I

I make no pretense that I can enforce my policy via XML.  What I said
was:

===
| >I must also be able to assert (not enforce) via my
| >markup that this view is mandatory (if it is).

===

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

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

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

| >An example directly contrary to your point about prefetching: there must
| >be a way in which I can specify that an XML application *must* fetch
| >the linked copyright notice and display it before the main text of
| >my fine literary work.  It may be that XML's linking mechanism is
| >not the place to do this, but if not, where do you think *is* the
| >right place?
| 
|    If you want a copyright notice for a document delivered over the web,
| you had better put it in the document, as the first text, because the
| network infrastructure is to frail for you to ensure that your readers will
| see it if it's anywhere else.

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.

|    I'm being rather harsh and flip with some very serious issues, but I
| don't see that the philospophical discussions will be solved here, nor do I
| think there are any technical solutions that we can offer to the problems
| you raise.

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

 1) state my conditions-of-use policy? 
 2) indicate the bounds of my multimedia work?

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


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 Sunday, 29 December 1996 12:45:46 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 10:03:50 EDT