From: "Frank Boumphrey" <firstname.lastname@example.org> To: <email@example.com> Date: Fri, 20 Mar 1998 16:32:08 -0800 Message-ID: <01bd5460$c7d41300$LocalHost@uspppBckman> Subject: Future of HTML Future of HTML Proposer contact: firstname.lastname@example.org 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.