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.
- There will be a need for HTML documents to display XML
documents as inclusions in their flow.
- 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.
- 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).
- 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.
- The XML document in its wrapper should have the ability to
import style sheets, scripts, entities, and other XML
documents.
- 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.
- 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.
- Any special attributes should be completely compatible with and
leverage the ongoing W3 work on CSS and the Document Object
Model.
- 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^gt;|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 <XMLPROLOG> 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 e 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 PROLG would normally appear.
In other words they would not enter in to the well formedness of
the document.
The main value of the XPROLOG would be to contain entities and
possibly notation declarations.. It is doubtful that there would be
any need for validation in a document contained in an HTML
document.
The above would act in just the same way as their HTML
counterparts, but they would be accessible only to the contained
document.
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 content of the XMLDOC
wrapper.
Linking
Simple linking from within the container should be
supported.
User agent behavior
- At a minimum the user-agent should keep a record of the whole
content, tags and all. This will allow parsing by scripts.
- The user-agent should expand any entities in XMLDOC before
passing them on to DOM.
- The user agent should keep an array of the children tags and
their content
- The user-agent should be able to re-flow in response to
actively generated flow objects.
- The user agent will need to recognize that XML tags are case
sensitive, when it makes its collections for the DOM
- The user agent will need to recognise PI's and notation
declarations even if in cannot act on them.
Respectfully submitted,
Frank Boumphrey.