Re: How to put XML on the Web

At 15:58 24/3/97 -0500, Alan Karben wrote:

>><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:

There is nothing here to override the formatting control of any stylesheet
attached to the document. All this is saying is that if there is no
stylesheet attached treat it as if you saw an HTML ... It does presume,
however, that XML browsers inherit HTML characteristics - not a bad
presumption if XML documents are supposed to be able to reference other
documents already on the WWW.

>><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. 

This shoehorning is the only way I can see of introducing concepts such as
Forms into XML without having to re-invent the world. Like you I see form
processing as key to the success of XML. The only way I can see to do it is
by clearly stating we are borrowing HTML behaviour. While this buys us
little with text elements for which stylesheets are a more elegant example,
it buys us masses for anything where HTML is associated with behaviour.

Whilst I agree the example looks inelegant the quoting issues are beyond my
control. (I left them out originally, and then remembered that they are
compulsory for XML. For html-atts I needed multiple tokens. I used a
semicolon as a separator originally, before reverting to spaces to tokenize
the mapping.)

>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. 

What we need to do is to deliver content-describing XML in a way that is as
easy to present to users as a format-describing HTML file.

>>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 --
>http://www.microsoft.com/finserv/news/ofxpr.htm

This example is well known - but highly limited in what it can acheive for
Electronic Commerce in general. Try writing an order and delivery note using
OFC!

>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. 

In no way is this a loose thought - it is key to the success or failure of
XML. What we need is a way of allowing user-specific fields in forms. E.g. a
part number and part description field where both entries are completed
using a single selection from a database, and are inseperable for the rest
of their history.

The behaviour of radio buttons and selection menus has already been well
defined in HTML. I see no reason for re-inventing the wheel. I submit that
what we need to do is to invent an easy way to inherit behaviour from HTML
tools.

>* 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
>documents?

Obviously SGML:-) (Me biased! - Never! Just look at the company name!)

>* Forthcoming Dynamic HTML will prove very useful. Can XML/DSSSL compete?

They have to to survive.

>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.

Agreed - hence my cry for behaviour on links if not elsewhere.

>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.

No it doesn't. What about those elements that are not expressible in HTML,
such as the maths, chemics, .... which are what differentiates SGML
publishing from Web publishing.

> 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....)

Every element in an XML file is an event - not just the few describable
using Dynamic HTML.
----
Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK 
Phone/Fax: +44 1452 714029   WWW home page: http://www.sgml.u-net.com/

Received on Tuesday, 25 March 1997 08:05:26 UTC