[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] DTD meta data for XML viewers
(this is a retransmit - the previous version was truncated) In an earlier note I spoke about the need to associate compose-time meta data with DTDs to allow XML editors to assist with the process of document composition. Another major class of meta data that needs to be associated with DTDs is information on how the associated XML may be rendered - most usefully, by identifying programs which can perform the required rendering. The classic browser renders HTML on computer screens, and also on the printed page. The same will be required of XML browsers, and some will also render XML documents to voice for the visually impaired, to braille for the more profoundly impaired, and to other media as new needs and technologies arise. Hence we may need to associate a list of rendering programs with any given DTD, covering the various media types supported. Current browsers attempt to render "all" HTML tags, but HTML is a moving target. Browsers are already very large, and need to be supplemented by plug-ins to handle various MIME types. Once XML is generally available, we must expect a proliferation of DTDs by various parties for varied purposes. While a single generic XML editor may do a good job of checking the syntax of documents developed against these DTDs, it cannot render them. Realistically, creators of novel DTDs will have to create code that renders them. And once a useful body of DTDs has been developed, authors of XML documents will want to use DTDs from many different independent sources in a single document. No browser manufacturer will be able to bundle rendering code for all DTDs into a single product. We need to define a standard way in which browsers can obtain and use code to render DTDs that were not even invented when the browser was created. This code distribution mechanism may be something between a plug-in, which requires manual intervention to install and persists after use, and a Java applet, which installs automatically and is discarded after use. For the purpose of this note I will call them "renderlets". We need to arrive at a standard way of associating renderlets with DTDs as meta data, so that browsers that encounter a DTD for the first time can find and obtain the code required to render the XML defined by the DTD. Some vendors may wish to create platform-specific and even browser-specific renderlets, giving rise to the need to associate a list of different renderlets with a given DTD. Most authors of DTDs will want to implement only a single renderlet to save effort. This would have to be platform and browser independent, and Java is the obvious choice. We need a standard way for Java renderlets to interface with the browser that invokes them. And since XML entities may be imbedded in other independently created XML entities, renderlets must also implement the same standard interface when they invoke imbedded renderlets. This interface will have to be richer than the current spartan <APPLET> tag, which makes an unconditional demand for display space. Any given XML document may in the future be rendered on anything from a IMAX screen to a Dick Tracey style watchtop display. Renderlets will have to share the space available. The browser will have to sum the space demanded by the renderlets it hosts and compute an overall compression factor. It will have to communicate the compression factor back to the various renderlets so they can make an informed decision about the level of detail that they display - if any. The renderlet interface will need to include a specialised Java LayoutManager to facilitate layout and space negotiation. Given this approach, the browser itself can become a fairly small and simple shell, with all XML elements implemented by downloadable renderlets. A cottage industry in renderlets may emerge, paralleling the VBX and OCX industry that Visual Basic spawned. Competing versions of renderlets for commonly used DTDs will arise, and browser owners will be able to shop around for the renderlets that best meet their needs. If there are concerns that fetching renderlets will generate excessive network activity and make XML browsers too slow to use, browsers (and http proxy servers) could be enhanced to allow priming of their cache directories. Pointers to local copies of often-used renderlets (and DTDs for that matter) could be loaded into the browser's (proxy server's) cache directory upon initialisation. Trevor Turton xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|