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