parallelism in presentation?

Mark D. Anderson mda at
Mon Dec 21 00:34:02 GMT 1998

Suppose I want a web page showing weather in several
parts of the world, aggregating content from a variety of servers.
I naturally want the loading of that constituent content to
be driven by the browser from those servers, in parallel.

Today, that can be done easily with the IMG tag.
If I want html loaded from different places, I either
have to use frames (gag), or some javascript hacks (gag again),
or something unportable such as activex or java (coughing up blood).

How would this work in the xml/xsl/xlp future?

Presumably I would start with a smallish xml file sent to the browser,
which has a variety of links to other xml content from other servers.
Those links would have whatever attributes are necessary to indicate that
the semantics are to pull in the pointed-to content as if it were inlined.

Now, some of that pointed-to content will load faster than others
in that page. Some will fail to load at all. Meanwhile, the layout
engine is hopefully able to do something useful. In particular, the
xsl style sheet may actually be suppressing some of the xml anyway,
so failures to load in those subtrees shouldn't matter.
While visible content is loading, it would of course be nice if bounding
boxes and temporary labels/content are shown.

This basically requires a layout engine that can act on the xml
with the xsl pattern matches acting as closures when the actual "expanded" xml
isn't available yet.

Has this all been spec'd yet? Are there working examples?
What is the right terminology? What does this mean for the DOM?

It strikes me that this isn't a "nice-to-have"; this issue is going to
have to be confronted somehow as soon as xml becomes more available on the web.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as:
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list