Re: unmarked linkend awareness by XML engines

David Durand writes in response to Steve Newcomb:
| >> Which documents are
| >> processed is not necessarily our concern.
| >
| >I disagree with this assertion.  If XML supports ilinks, there must
| >certainly be a way of establishing a finite list of links for which
| >the XML engine is responsible for knowing the anchors (er,
| >"linkends").
| 
| No, this is at least in part the user's responsibility. The engine must be
| responsible for being able to provide information about links _contained
| in_ a document. Other links to that document will only be found if the user
| has explicitly or implicitly (via some strategy) specified what other
| documents may contain ilinks of interest (for example by opening a bookmark
| set of ilinks, or a guided tour set of ilinks, or an annotation set of
| links, etc.).

So far so good.

| >(Otherwise, the XML engine must be responsible for all
| >the XML links on the entire Web, which I think we all agree is an
| >insupportable scenario.)  This means establishing, somehow, a finite
| >list of documents that contain such links.  HyTime calls such a finite
| >list a "Bounded Object Set" (BOS).  In HyTime, the BOS is always
| >application-definable, but it is also expressible interchangeably, as
| >a suggestion, in terms of an arbitrarily pruned entity tree.  If XML
| >supports ilinks, or n-directional linking, or, therefore, what I have
| >been imprecisely terming "anchor awareness," I think it's necessary to
| >have a way of expressing this pruned entity tree (BOS) notion in XML,
| >too.

BTW, Steve, what is the current specification of a BOS?  Has it been
changed by the TC?

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

| check the whole world, and we can't just leave it to the author (without
| damaging the ability to create external annotations), so we have to leave

XML should not have as a design goal the ability to enable promiscuous
external annotations unauthorized by the document's owner.  The owner
may wish to enforce a policy that he does not permit the work to be
viewed with annotations (e.g., by not serving to clients that do not
guarantee to respect his policy).  We are under no obligation to
enable grafitti.  We may be powerless to prevent it, too.

| it to the user (via their application). In other words, XML as a standard
| cannot enforce this kind of scoping for the user. All that we need to
| specify is how ilinks behave in documents where they are _parsed_ by an XML
| processor. In HyTime terms, the BOS will always be the entire web (one of
| the reasons I always thought the notion was limited in usefulness).
| However, the set of documents an XML processor will be required to
| processes is an application (user) decision. As an example we could not
| force a browser to pre-fetch linked documents in case they might reference
| ilinks that _might_ be of interest.

But we must have some mechanism to indicate to the user agent what the
bounds of a single work are, something lacking on the Web today.  This,
too, may lie without the scope of XML linking, but we still need it.

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?


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, 28 December 1996 19:19:47 UTC