Re: Future of HTML

    The following is offered as a very "quick and dirty" demonstration of
the <XMLDOC> tag and an <XSTYLE> style sheet in my proposal. It uses the IE4
version of the DOM so it will not run on Navigator, and I have only tested
it on a PC, but it should work on any platform with an IE browser.

    There is an alert which shows the HTM code generated, comment out all
references to htmstring to get rid of it.

    It employs the "cheat" of enclosing an <XMLDOC> tag within a <DIV> tag
with its id set to "xml".

    It is meant as a demonstration of how easy this wrapper would be to
implement.  the .js file is here as attachment js2.js, the htm file is also
atttached as js1.htm

    I have also posted this to the css and the XSL list in case it is of any

    Frank Boumphrey
ps. written in strict emacs
<TITLE>Demonstration of XMLDOC tag</TITLE>
<DIV id=xml style="display:none;">
 <document>Some extraneous text
  <greeting voice="nice">Hello world</greeting>
  <greeting>hello xmldoc tag</greeting>more extraneous text
  <insult>Hiss off you <emphasis>stupid<extraem>stupid</extraem></emphasis>
old fool </insult>
  more extraneous text
  <!--a comment-->
<SCRIPT SRC="js2.js">
//this script must be placed after the XML document.
 var tagnames=new Array();

 for (i=0;i<=xml.all.length-1;i++)


-----Original Message-----
From: Frank Boumphrey <>
To: <>
Date: Friday, March 20, 1998 1:27 PM
Subject: Future of HTML

>         Future of HTML
>             Proposer contact:
>                     Name: Frank Boumphrey
>                       Tel:  440-338-3302
>                  Proposal for an XML wrapper
>  ------------------------------
>     As authors and businesses and web authors move over to XML based data
>bases and
>documents there is going to be a need to embed XML documents in existing
>HTML documents.
>     This proposal discusses achieving this through a wrapper <XMLDOC>, and
>supporting attributes and Tags to service the primary tag.
>     In XML a tag beginning with the sequence XML is not allowed as these
>tags are reserved.
>XMLDOC however is not an XML tag it is an HTML tag.
>    Basic considerations and presumptions.
>    --------------------------------------
>     The following issues will need to be considered.
>     1.There will be a need for HTML documents to display XML documents as
>inclusions in
>their flow.
>     2.The contents of the XML document may either be known to the HTML
>before hand (as when the XML is authored concurrently with the HTML
>document), or the XML
>content may be unknown to the HTML author (as when the XML document is
>imported). In the
>first case it may be beneficial for the XML elements to inherit the style
>properties of the parent
>HTML document (e.g. via. Inheritance from the parent style properties or ID
>and CLASS
>attributes), in the second case the XML content should probably be "hidden"
>from the parent
>     3.The XML document may need to be displayed, or it may act as a
>resource for a client-
>side script to manipulate ( as when the XML document acts as data source).
>     4.With the above in mind the XML wrapper should have provision for
>providing default
>display, associating the XML content with style sheets, and associating the
>XML document with
>     5.The XML document in its wrapper should have the ability to import
>style sheets, scripts,
>entities, and other XML documents.
>     6.There may be more than one XML document within the HTML containing
>There should therefore be provision for a single external XML style sheet
>and/or script to handle
>all these documents.
>     7.It should be easy to author active-X components or plug-ins to work
>in conjunction with
>the current browsers. Note that the issue of using an XML wrapper is quite
>different from using
>an XML compliant browser.
>     8. Any special attributes should be completely compatible with and
>leverage the ongoing
>W3 work on CSS and the Document Object Model.
>     9. Any tags should be forward-ly compatible to easily meet future
>Default Behavior
>     In the absence of any attributes being set on the XMLPROC tag, each
>child tag should be
>ignored and the content treated as a inline flow object inheriting the
>parent styling. This is in fact
>the way that the current mainline browsers should (and do) treat the
><XMLDOC> tag or any
>unknown tag
>The XMLDOC tag and the HTML flow structure
>It is an open question whether the descendant tags in the XML document
>should enter into the
>HTML DOM or whether they should form their own tree. If they form part of
>then they can be operated on by Script outside of the XML doc tag.
>     If the content attribute (see below) is set to visible, then they
>should probably be exposed
>to the whole document, if set to hidden then they should probably be kept
>completely self
>     The following is a possible list of attributes (Modified EBNS syntax)
>     Content (Hidden|Visible) "hidden"
>     If set to hidden then the XML document is shielded from the rest of
>document. This means that outside scripts, style sheets etc. will have no
>effect on the document.It
>is even possible that an id value in the xml document may be the same as an
>id value in the HTML
>     The default value should be hidden
>     src <url>|none
>     Can be used to import an XML document into the wrapper. To prevent
>with well formed-ness only one XML document per XMLDOC element should be
>allowed. This
>should not prevent the importation of entities. See <XPROLOG> below.
>     render (visible|hidden|partial) "visible"
>     To be distinguished from content, and similar to the CSS visibility
>property which
>cold be used instead. A value of partial would allow display of some of the
>element content by a
>mechanism yet to be determined.
>     importstylesheet [[url],]*.
>     Several style sheets can be imported and a cascade would be allowed.
>The first in a
>tokenized list of URL's would be the first to be imported. These style
>sheets would be invisible to
>the rest of the HTML document and would be encased in an <XSTYLE> tag
>     ImportScript [[url],]*
>     The same considerations would be applied to imported Scripts.
>     string [[<cdata>],]*
>     In keeping with XML this attribute could take one or several strings.
>     plus id, class, style, name, dir, and lang
>     If  the value of content is hidden then no styling will be passed to
>the XML content
>by default. However if the XMLDOC has its class set to a style then that
>style can be passed to
>the contents. The same if style is specified by way of an inline tag.
>Contained special tags
>     The following tags can be employed inside the <XMLDOC> element. They
>should appear
>where the PROLOG would normally appear, at the head of the document. In
>other words they would not enter in to the well formedness of the document.
>      XPROLOG
>     The main value of the XPROLOG would be to contain entities and
>notation declarations. It is doubtful that there would be any need to use a
>DTD for validation in a document
>contained in an HTML document.
>     XLINK
>     XSTYLE
>     The above would act in just the same way as their HTML counterparts,
>but they would be
>accessible only to the contained document.
>     @import
>     As in CSS this can be contained in an XSTYLE wrapper to import further
>style sheets.
>     <STYLE TYPE= "text/css">
>     </STYLE>
>     <SCRIPT>
>     </SCRIPT>
>     A further container at the head of the HTML document could contain
>elements that would
>only apply to contents of the XMLDOC wrappers.
>     Simple linking from within the container should be supported.
>User agent behavior
>    The following is a list of behaviors that user agent, s might support.
>     1.At a minimum the user-agent should keep a record of the whole
>content, tags and all.
>This will allow parsing by scripts.
>     2.The user-agent should expand any entities in XMLDOC before passing
>them on to
>     3.The user agent should keep an array of the children tags and their
>     4.The user-agent should be able to re-flow in response to actively
>generated flow objects.
>     5.The user agent will need to recognize that XML tags are case
>sensitive, when it makes
>itscollections for the DOM
>     6.The user agent will need to recognise PI's and notation declarations
>even if in cannot act
>on them.
>    Respectfully submitted,
>        Frank Boumphrey.

Received on Saturday, 21 March 1998 23:26:46 UTC