Re: Serving generic XML (was: storing info in XSL-FO: new issue?)

Stuart Ballard <[email protected]> Fri, 23 Aug 2002 16:07:01 -0400
Newsgroups gmane.comp.web.general
Message-ID <[email protected]> 
[leaving www-style in, because (a) I don't read www-talk and (b) my=20
reply moves things back towards being on-topic for that group (in that=20
it is primarily concerned with stylesheets as a way to approach the issue=
)]

Etan Wexler wrote:
>=20
> As H=E5kon has written, it's a question of stepping in the right
> direction, moving from formats that are inaccessible to formats that ar=
e
> more accessible.  From this perspective, XML of unknown document type h=
as
> its place.

I'm going to repost this here because the subthread in which I initially=20
replied had an inflammatory subject line (WAI: threat or menace?) that=20
may have discouraged people from even looking at posts in it. I=20
encourage people to go back and look at the parent from which I'm=20
quoting, too: it was among the more intelligent and thorough posts made=20
on this topic so far. But my own comment was (starting with a quote):

Kynn Bartlett wrote:
 >
 > 2.  Another idea might be to require that XML documents be sent
 >     with an appropriate style sheet if the XML is intended for
 >     display to users (and not merely computer-to-computer
 >     communication).
 >
 > 3.  Here's yet another idea -- develop some sort of meta-language
 >     which can be used to assign meaning to particular elements in
 >     arbitrary XML, thereby telling the user agent what the language
 >     means.

Seems to me that by combining these two ideas, the problem can be solved=20
*today* (at least if you're willing to disregard all but the very newest=20
browsers - in the near-ish future, at least, if you aren't).

My thought is that the best way to "assign meaning to particular=20
elements in arbitrary XML" is to use XSLT to transform those elements to=20
another language which already carries such meaning. Such as (gasp) XHTML=
!

In other words, send generic XML by all means, and put as much=20
(domain-specific and therefore unknowable to the browser) semantic=20
content in it as possible. But accompany it with an XSLT stylesheet that=20
transforms it into XHTML using XHTML's slightly lower-level semantics.

For example, your XSLT could transform this:

<singer>
   <name>Madonna</name>
   <album name=3D"Ray Of Light">
     <song name=3D"Ray Of Light" released=3D"true">
       <release date=3D"2001-xx-xx" />
       <lyrics>
         <verse>...</verse>
         <chorus>...</chorus>
       </lyrics>
     </song>
   </album>
</singer>

Into this:

<h1 class=3D"singer">Madonna</h1>
<h2 class=3D"album">Ray of Light</h2>
<h3 class=3D"song">Ray of Light</h3>
<p class=3D"released-on">Released on <span class=3D"date">xx Xxxxx=20
2001</span></p>
<h4 class=3D"subhead">Lyrics</h4>
<blockquote class=3D"verse">...</blockquote>
<blockquote class=3D"chorus">...</blockquote>

(along with the <html><head>... stuff of course).

Now the higher-level semantics "this is a singer" are not lost, and a=20
smart client (eg an MP3 player?) can read the original XML directly. But=20
a "dumb" client like a web browser still gets access to the lower-level=20
semantics "this is a headline, this is a lower-level headline, this is a=20
longish quoted section of something". Further, the XHTML can include its=20
own CSS stylesheet to indicate a suggested rendition for traditional=20
graphical browsers, without compromising the capability of=20
accessibility-browsers to ignore the stylesheet and render headings in a=20
way that's useful for that specific device. If the author is=20
particularly interested in certain accessibility markets, CSS=20
stylesheets for aural and/or braille representation can also be=20
included, but these aren't necessary because the aural or braille=20
browser has default stylesheets for XHTML that will do the job (contrast=20
to the "require all arbitrary XML to be sent with a CSS stylesheet"=20
position, where all arbitrary XML must include stylesheets for *all*=20
media if it is to be accessible).

In the future, it's possible that XML vocabularies with higher levels of=20
well-understood semantics will become widely distributed, so that you=20
can say "this is a credit card number, this is a date, this is a name"=20
etc. When that happens, the same trick can be used - use XSLT to=20
transform from the domain-specific semantics to the lower-level=20
publically-understood semantics. And for legacy browsers, XSLT can also=20
further translate these down to the still-lower level of semantics=20
implicit in XHTML.

Stuart.

--=20
Stuart Ballard, Programmer
NetReach - Internet Solutions
(215) 283-2300, ext. 126
http://www.netreach.com/