Re: Ephemeral XML?
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?
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.