Future of HTML

         Future of HTML

             Proposer contact: bckman@ix.netcom.com
                     Name: Frank Boumphrey
                       Tel:  440-338-3302


                  Proposal for an XML wrapper
  ------------------------------

Introduction
------------
     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
discusses
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
document
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
document.

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

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

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
the HTML DOM
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
contained.


Attributes
------------
     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 the
HTML
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
document.
     The default value should be hidden


     src <url>|none

     Can be used to import an XML document into the wrapper. To prevent
problems
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 possibly
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
     XSCRIPT
     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.

ExternalTags
------------
<XMLPROLOG>
     <STYLE TYPE= "text/css">
     </STYLE>
     <SCRIPT>
     </SCRIPT>

</XMLPROLOG>

     A further container at the head of the HTML document could contain
elements that would
only apply to contents of the XMLDOC wrappers.


Linking
-----------

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

     3.The user agent should keep an array of the children tags and their
content

     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 Friday, 20 March 1998 16:25:53 UTC