[unrev-II] Editing XML Outlines: A Workaround

From: Eric Armstrong (eric.armstrong@eng.sun.com)
Date: Fri Jul 14 2000 - 15:16:15 PDT

  • Next message: John J. Deneen: "[unrev-II] Use Cases/Mockup Views Demo: SamePage, Take Action! & WebProject Collaborative Management Technology"

    In one of my writeups at www.treelight.com/software, I
    described two deficiencies of XML that will tend to limit
    it's future as a ubiquitous data standard. (Ideally, XML
    will become as ubiquitous as plain text -- but plain text
    has achieved it's ubiquity because it is editable using
    any number of editors. An editor needs no special knowledge
    of the text to do a creditable job. Most XML editors, on
    the other hand, require special schema-controls to deal
    with the structures intelligently.)

    Basically, two things are needed:
      * A standard allows an arbitrary editor to know which tags
        are inlinable. (The xhtml "inline" declaration could
        possibly be used.)

      * Some mechanism by which mixed-content can be constrained
        to occur only *before* the first non-inlinable element.

    The lack of a standard that distinquishes inlinable elements
    produces XML "outlines" that look like:
      <p>This is a
         <b>word</b>
         in a
         <i>sentence</i>
         .
      </p>

    Here, tags that are intended to be "part" of the text are
    displayed as elements in the outline, because the editor doesn't
    recognize them as inlinable.
         
    Meanwhile, lacking the ability to constrain mixed-content (text
    plus inlinable tags) so that it only occurs before the first
    noninlinable element forces you to add extra elements, solely to
    create the separation. So, in DocBook, you have
      <sect1>
         <title>...</title>
         <sect2>...</sect2>
         <sect2>...</sect2>
      </sect1>

    Note that <sect1> has no text at all. The text, plus any inlinable
    tags, are part of the <title> element. That separation lets the
    parser verify that there is no dangling text between the <sect2>
    elements, for example, where it wouldn't make any sense.

    But the extra element make for an "outline" that is one step removed
    from the logical structure you intend. Coupled with "inline" elements
    that display as though they are part of the outline structure, the
    result is a difficult, non-intuitive editing experience (unless
    special schema-controls are defined to guide the editor).

    On the other hand, if inlinable elements can be identified, and
    the extra text-containing element can be removed, then intelligent
    outlining becomes feasible. However, without modifying the XML
    standard to accomodate such changes, one workaround is still
    conceivable:

       Because XML forces you to create a second tag to hold
       the content of a section (e.g. DocBook <sect1> + <title>),
       and because the content element (viz. <title>) is a
       mixed-data model and while the container (<sect1>)
       presumably *isn't*, it becomes possible to implement the
       following algorithm for outlining:

         1. If an element is *not* a mixed-content element,
         2. And it's first subelement *is* a mixed-content element,
         3. Then ignore the tag for the subelement when constructing
            the outline, and display its content as though it were
            in the containing element. (When editing, of course, be
            sure to store any changes back in the subelement.)

    With that mechanism, instead of displaying:
      <sect1>
         <title>A
         <sect2>
            <title>1
         <sect2>
            <title>2

    You can display a more normal "outline":
      <sect1>A
         <sect2>1
         <sect2>2

    The latter version conserves vertical whitespace and corresponds
    more closely to what we intuitively think of as an "outline".
    The data would still need to be stored in the first format, due
    to XML's limitations. But if data were visually displayed and
    edited using the second format, I believe it would go a long way
    towards making XML "ubiquitous" in the same way that unstructured
    text currently is.

    ------------------------------------------------------------------------
    Respond.com - Technology Solutions for your Business!
    http://click.egroups.com/1/6828/5/_/444287/_/963612890/
    ------------------------------------------------------------------------

    Community email addresses:
      Post message: unrev-II@onelist.com
      Subscribe: unrev-II-subscribe@onelist.com
      Unsubscribe: unrev-II-unsubscribe@onelist.com
      List owner: unrev-II-owner@onelist.com

    Shortcut URL to this page:
      http://www.onelist.com/community/unrev-II



    This archive was generated by hypermail 2b29 : Fri Jul 14 2000 - 15:23:31 PDT