DTD meta data for XML viewers

[Tony Stewart]

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 at rivcom.com
Web:	www.rivcom.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)