History for LinkObjects

??changed:
-
Link Objects

  Culprit: Ken Manheimer

  This is a proposal for a new type of elementary zope object,
  LinkObjects, and a LinkRegistry, by which content links are
  explicitly surfaced, and inherently track the location of other
  local content elements.

  Use the 'Reply' link in the Actions box to comment - suggestions,
  questions, corrections, etc. are welcome.

Problem

  The *interlinking* between pages is, itself, a manifestation of
  content on a site.  Not only must a content management system help
  site managers and contributors with the evolution of the content
  pages, it must also provide for the critical challenge presented by
  evolving site organization.  It needs to provide for a way to have
  content links track relocation of target content elements.

  Not all position changes should be tracked, however.  Editors need
  the discretion to move content *out* of targeted slots without
  tracking.  We need to distinguish between tracked relocation and
  non-tracked moves.

  Finally, we need to keep an eye towards the future, when syndication
  or other site federation mechanisms could provide for tracking of
  reorganization across sites.

Context

  Content management includes interconnection between bits of content
  - linking - as well as the contents of the pages themselves.

  The Zope catalog internally maintains a sort of registry that may be
  applicable to this task.  It maintains an internal mapping from an
  id for each object tracked by the catalog and the object's physical
  path.  For objects that are actively cataloged, the catalog
  effectively is notified about and tracks location changes of an
  object, as well as changes to its content.

  Organization Objects (see OrganizationObjectsProposal) are intended to be based
  on a generalization of something like the catalog, where a registry
  for various kinds of content relationships, not just text-specific
  indexes, is maintained.  This proposal fleshes out part of that
  superstructure, sketching a requirement that uses something like the
  catalog's object-location registry for purposes beyond text-index
  resolution.

Forces

  Digital Creations is increasingly focusing our efforts with Zope on
  content management, and management of the organization of a site is
  an important component of that job.  In particular, Zope's
  flexibility makes it a prime vehicle for managing rapidly changing,
  evolving sites.  This is an area where we can excell - and, in the
  emerging web-speed world, an area with ever increasing demand.

  There are many uses for explicit recognition of a piece of content's
  links in addition to change tracking.  The Dublin Core 'Relation'
  attribute represents general concern with this piece of metadata.
  Backlinks and generic navigation links like next and previous
  represent structuring in a site, and so on.

Solution

  Provide a mechanism so interlinking between content on a site, and
  incoming links from outside, can automatically track changes in the
  organization of the site, when appropriate.

  Establish "link objects" --
    which indirect through an object location registry (like the one
    currently internal to the catalog) to get the URL (via
    getPhysicalPath()) of the the target objects.  DTML and ZPT based
    documents could expressly refer to these link objects.
    StructuredText could use these objects instead of substiuting an
    href for the desired text - and, in general, this sort of approach
    (see the next item) will probably be the primary way that link
    objects are employed.

  Translate content links to internal LinkObjects --
    For example, in html this would cover the URLs for href and name
    anchors, img src, etc.  StructuredText and other *ML formats have
    corresponding structures.  (I'm referring to something like what
    the "Parsed XML",
    http://dev.zope.org/Wikis/DevSite/Projects/ParsedXML effort
    provides - a fast, efficient DOM storage.)

    Note that the *expressed form* of the original link would need to
    be preserved.  This would be to enable presentation of new
    location in similar style - for instance, relative versus absolute
    links.

    [Ideally, translated documents like wvWave-parsed MS Word files,
    could be similarly manipulated, but i'm not clear about the impact
    on round-tripping or even whether editing via the wvWave parsing
    is possible.]

  Register Intrinsic and Explicit Link References Via Event Channel --
    A document's intrinsic content links and other link oriented
    metadata (many of which would belong in the DublinCore Relation
    field - see the "Implement the Dublin Core's Relation / Source
    Elements":metadata/dublin_core_relation proposal) are
    automatically propagated via the event channel (see the
    OranizationObjectsProposal) to the object
    location registry, and link objects are substituted for them in
    the document's internal representation.

  Provide a new "relocate" operation --
    (at user and programming levels), to contrast with the existing
    "move".

    "Relocate" would revise the indirection to the object to point to
    the new location, so internal links would track the change, while
    the old move operation would keep its old behavior, and not cause
    tracking of the change.

    This opens the door to collective reorganization operations, like
    moving offspring from a CommonNameSpaces
    page down to its own namespace, with all incident links to the
    pages tracking the change.

  Institute the object/location mapping for consumption outside the site --
    along the lines of the "XML Linking Language":http://www.w3.org/TR/xlink
    "'linkbase'":http://www.w3.org/TR/xlink/#dt-linkbase#dt-linkbase, 
    so that other sites can track locations.  (Presence of a linkbase
    entries for a document should depend on the document being freely
    published.)

  (Note that LinkObjects also offer the basis for presenting an option
  for content consumers (including the author, as well as other
  visitors) to create the target content of internal links that don't
  already exist, a la ", contingent to the user having the privilege, the
  feature being enabled, etc.  This will afford one of wiki's
  low-impedence features without being bound to specialized content
  types.  See CommonNameSpaces for
  more details.)

Resulting Context

  A system with rich link tracking options.

  Use cases:

  Editor Adds or Changes Content --
    Content links are assessed:

    - For some documents types, links are automatically identified

    - Some, the editor has to explicitly specify them as metadata

    - For all, user may be able to specify additional objects for
      metadata links - eg, next and previous, parents, etc.

    Links are propagated:

    - Event channel propagates edit commit, links assessed by
      LinkRegistry organization object.

    - If LinkRegistry is syndicated, updates to syndication partners
      are queued for immediate or eventual propagation.

    Links are internally represented as link objects.

    Links are externally presented via consultation with LinkRegistry
    - so they track current location, etc.

  Visitor Traverses Document Links --
    They track the current location, or can indicate a stale link
    without the user having to traverse them (like, eg, the red
    superscript 'x' that WikiForNow uses for absent-but-uncreatable
    targets).

  Visitor to External Site Follows Stale Incoming link --
    Publisher encounters "Not Found" condition, consults link registry
    to obtain new location.  If it's a relocated object (and published
    at new location), publisher returns http "Address changed/Revise
    your URL" status (or whatever that is, i forget) with new
    location.  If it's for a moved or deleted object (and the object
    is published), present an error page which indicates the new
    location.

  Editor *Relocates* Content --
    LinkRegistry entry for object is updated so incoming link references
    inherently resolve to new location.

  Editor *Moves* or *Deletes* Content --
    LinkRegistry entry for object marked as moved or deleted, but new
    location is not registered as being current.  Ie, incoming
    LinkObject references will not point to new location - but they
    can be set to indicate that they are broken until a new object
    falls into place, and even consulted for the new location.
    (LinkObjects can present links to a 'create' form for the absent
    target, if the feature is enabled and the visitor is privileged.)

  Editor Relocates Content Collection --
    Eg, via lineage 'gather' or 'merge' - all LinkRegistry entries are
    updated to track new locations.
[45 more lines...]