Re: How to put XML on the Web

At 08:42 AM 3/24/97 +0000, Martin Bryan wrote:
>Could I, perhaps, suggest, somewhat sheepishly, plan BA - HTML+- -:)
>The problem is that we all want to make as much use of what is already known
>by an HTML browser without having to restrict users to HTML. For basic text
>elements we will need a way of mapping the text elements in our XML
>documents to standard display semantics used for HTML. For example, I could
><para html-equiv=p>I must <hp1 html-equiv=em>emphasise</hp1> ....

The hybrid presented above is bound to cause the publisher to lose
formatting control, even if attributes are somehow slipped in:

><logo html-equiv="img" html-atts="src=file ismap=treat-as" file="fig1.gif"
>treat-as="ismap"> ...

The shoehorning doesn't buy you 'backwards-compatibility,' and the quoting
issues and general inelegance would prove problematic, I'd bet. 

HTML/CSS, with the "class" attribute, is essentially the inversion of the
above, allowing authors to sneak in a single content-describing tag inside
an HTML attribute. This too is limiting because (a) it precludes
content-describing attributes, and (b) it only drives formatting.

The key point here, I believe, is for us to emphasize the difference
between delivering information in format-describing HTML or in
content-describing XML. The only point in doing the latter is to facilitate
client-side processing and reuse. 

>Where I, personally, would like to see XML positioned is as HTML Extensions
>for Electronic Commerce. 

Sounds great to me, except for the need to mention "HTML." Check out the
Open Financial Exchange DTD, to be integrated within Microsoft Money,
Quicken, and CheckFree applications --

>The ability of XML files to link with company databases is, I would suggest,
>the key to success. The inability to link documents to databases sensibly is
>one of the major stumbling blocks in current systems design. 

I couldn't agree more. I've posted a separate mail to exercise how XML
links could connect companies mentioned in WSJ stories to our customers'
internal databases.

A couple of loose thoughts:

* XML equivalents for <form> is critical. Paul's DSSSL exerpt seems good,
though there must be an attribute that links (id/idref style?) groups of
radio buttons together and ties input objects to get/post URLs. 

* If XML proves popular for delivering content, publishers will still in
the vast majority of cases have different authoring-side and client-side
documents. Good document architectures will include transformation steps to
fill in path names, navigational contexts, advertisements, etc. This has
many ramifications vis a vis the question: When is it best to format the

* Forthcoming Dynamic HTML will prove very useful. Can XML/DSSSL compete?
I'm more familiar with OmniMark & perl tools for manipulating SGML, and can
think of more than a few things our readers could do if they could activate
client-side scripts to 'regenerate' the content for different Views.

(Vendor Note: At the OmniMark User's Group meeting in December, their
management stared pretty blankly when asked about lightweight, run-time
copies suitable for client-side manipulations ;-)

Since the DSSSL formatting step is last on XML-WG's list, and folks here
seem to describe a need to take advantage of (reuse) the browsers' current
HTML rendering capabilities, how about a plug-in module to convert text/xml
into HTML? That gives you the formatting. Making calls to this rendering
module from Dynamic HTML _events_ gives you the custom database
integration. Writing to cookies makes the per-XML-site customization
settings persistent. (Just scrawling on the virtual whiteboard here....)


    Alan Karben
    Manager, Multimedia
    The Wall Street Journal Interactive Edition

    karben@interactive.wsj.com    phone: 609 520 7361
    http://wsj.com                  fax: 609 520 7137