Re: Ephemeral XML?

Ralph writes:

   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.

1. It's also the simplest to sell to the users: "look, this is HTML with
bells and whistles on"...

   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

2. One way would be if such XML browsers started that way, as a
demonstration of the possibilities, and grew into fully-fledged HTTP
browsers so good that they made MSIE and Netscape look sick :-)

   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. 

3. It switches to "rough-parse" mode, hacks what sense it can out of such
markup as there is, and puts up a nice little icon that says "non-HTML
file", and hands it _to_ MSIE or Netscape for display :-)

   That means the code for dealing with (for
   example) FORMs and APPLETs has to be built in. 

4. The above scenario avoids that problem.

   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? 

5. Yep.

   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?  

6. By the style-sheet definitions for these elements being absent (or
indeed the stylesheet being absent). In which case the XML browser
either does the form using default formatting (if capable) or sticks
up the above flag and hands it to a non-XML browser.

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

7. This is probably what they will do anyway, whether or not we define XML.

   So I don't see looking to Netscape and Microsoft as the folks who make XML
   - as currently defined - happen. 

8. Right. GOTO #2.

   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

Ping. Form _submission_ is a type of hyperlink. I'm not sufficiently
well up in hypertext theory to say if the data transferred can be
considered as "part of" a hyperlink.

   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.

But I thought the point about AFs was that -- among other things --
they can be used to define the semantics of specific [read: expected]
actions which can be associated through a DTD with certain
elements. So AFs of class "info-to-be-sent-somewhere" or
"element-to-be-filled-by-received-info" (aka transclusion, *gasp*) or
"perform-processing" (aka PI) can be mapped to FORM, ISINDEX, APPLET,
EMBED, OBJECT, etc. You're right, though: the XML browsers will have
to exhibit smarts about what to do with streams of data that walk like
HTML and quack like HTML.

///Peter

Received on Monday, 13 January 1997 17:39:09 UTC