Cart
[Home] [By Thread] [By Date] [Recent Entries]
Trevor Turton wrote: >>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. >>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. I think these issues are real, but belong in the domain of the XSL discussion. Style, presentation and behavior are all aspects of the same thing: the transformation of the data/information into another, usually human-understandable form. (I say "usually" because you could use a style sheet to transform the information into a different computer-interpretable form without ever presenting it to a human being.) XSL can and should provide the tools that allow us to specify what transformation should be applied to our XML data, including taking into account issues like user impairment, new media, etc. It is the means by which we associate multiple possible presentations--and the mechanisms for choosing between them in a given presentational instance--with data encoded according to a single DTD or schema. Having said that, yes, we will need to implement robust presentational mechanisms in (preferably) thin clients, so all of these technical issues need to be addressed. But let's make sure that XSL stays in the loop. Tony =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Tony Stewart Director of Consulting, RivCom "Publishing Structured Information" New York, NY, USA and Swindon, UK Direct: +1 (212) 222-4332 Office: +1 (212) 662-6800 Fax: +1 (212) 662-6900 UK Tel: +44 1793 790 802 UK Fax: +44 1793 790 812 Email: tony.stewart@r... Web: www.rivcom.com =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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...)
|
