Re: Ephemeral XML?

At 03:03 PM 1/12/97 -0500, David G. Durand wrote:

>Even the most ambitious
>proposals we've made are not beyond Netscape and Microsoft's reach, I
>think.

As I wrote in an earlier message, I doubt that these companies will build XML
browsers from scratch. I believe they will *extend* HTML, rather than
implement XML. That is what many users will expect, and what is simplest to
implement. 

XML has to co-exist with HTML. There are two ways for that to happen. One
way is that an XML browser is a Panorama-style helper app that gets launched
when a non-HTML doc is being fetched. Netscape and Microsoft can leave that
kind of implementation to others. The other way is to create a "native" XML
browser, complete with HTTP client. But what happens when this native XML
browser fetches an HTML doc? It has to recognize the semantics of HTML. That
means the code for dealing with (for example) FORMs and APPLETs has to be
built in. Now what happens when the XML browser fetches an "XML document" in
which the user's intention was to add a few elements to the HTML tag set?
Does the browser treat the FORM and APPLET tags as generic markup and look
for a definition of these tags in a stylesheet? If so, how does the user
indicate that the default behavior found in HTML is what they want - and in
fact are expecting to happen without any additional effort on their part?
The simplest approach for Netscape and Microsoft is to say: "Our browsers
will handle existing tags as they currently do. Users, however, can *extend*
the base set by defining new tags through a stylesheet mechanism that we
provide." 

 So I don't see looking to Netscape and Microsoft as the folks who make XML
- as currently defined - happen. I believe Jon launched this effort largely
in fact to head off the foregoing sort of scenario.
  
>    KISS is good, but if we can't offer benefits over HTML, we may look
>stupid, since HTML has already got simple all wrapped up (and deployed).
>

But we also need to *include* the benefits that HTML *already* provides. One
of XMLs main target audiences is supposed to be publishers. Publishers
commonly use a FORM to request input from users. Unless the behavior
associated with an HTML FORM can be assumed, a publisher would have to go
back and redefine - somehow - the semantics associated with that element for
use with an XML browser. Since FORMs are used to input queries, they can be
considered as a type of hyperlink and so support for them should be included
in this discussion anyway. I believe though, that support for other HTML
semantics (e.g., SCRIPT, OBJECT, APPLET - elements whose be behavior can't
be replicated with just a stylesheet) will need to be included as well. In
other words, an XML browser would default to the HTML-defined content model
and behavior associated with these elements. If you want something else, you
have to *override* that behavior, either through a stylesheet or by
specifying compliance with an architectural form.


Regards,

Ralph E. Ferris
Project Manager, Electronic Publications
Fujitsu Software Corporation

Received on Monday, 13 January 1997 10:38:32 UTC