W3C home > Mailing lists > Public > www-talk@w3.org > November to December 2000

Re: Semantic Document Framework(s)

From: Kurt Cagle <cagle@olywa.net>
Date: Fri, 10 Nov 2000 11:37:56 -0800
Message-ID: <001001c04b4d$bbe117f0$60c8fdce@siren>
To: "Sean B. Palmer" <sean@mysterylights.com>, "Aaron Swartz" <aswartz@swartzfam.com>
Cc: <www-rdf-interest@w3.org>, <www-talk@w3.org>
> > > How do you transform HTML into WML 1.0/1.1? You can't because they are
> so
> > > different, HTML is so much more complex than WML.
> >
> > Speaking as the author of a piece of software that converts HTML to
plain
> > ASCII, I'm pretty sure HTML can be transformed into nearly anything. ;-)
>
> Speaking as someone who has tried a million times to make a useful XHTML
to
> WML conversion tool, I can tell you that you lose an awful lot of the
data,
> becuase images, scripts, forms and so on, cant be readily converted. Not
> saying it's impossible, just very very hard.

Actually, the biggest problem with conversion of WML to XHTML is that they
exist at different process levels. An XHTML document exists as a single
process (assuming no complex scripting or other work to make client
"wizards" possible). WML, on the other hand, is a set of discrete
processes - a card in a deck is a single process.  The two are fairly
radically different design constraints, and get back to a fairly deep
semantic problem that the comparative simplicity of the two languages tend
to hide. One solution that I've found is to recognize that it is far easier
to design XSLT transformations that combine multiple processes (call them
document chunks) into a more complex page than it is to take a web page and
break it into distinct WML processes.

There's actually a lesson here, I think. Analysis of documents is a largely
human activity, and requires extremely sophisticated programming tools to
duplicate in an autonomous environment. On the other hand, the synthesis of
doclets into cohesive superstructures can be easily automated, can be easily
monitored, and provides far greater flexibility to target multiple output
forms. The disadvantage here is that most of the tools we have for content
generation are macular -- they confuse flexibility of content generation
with flexibility of content display. Moreover, the server architectures that
we have also tend to reinforce that macular concept -- a web page is easy to
write but a sequence of web forms (which is in essence what WML is) require
more sophisticated processing. Thus I don't see a clean HTML to WML map any
time soon, while a WML to HTML map is almost trivial to write. I don't think
this is an insignificant aspect of building a semantic web.

-- Kurt
Received on Thursday, 9 November 2000 14:38:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:24 GMT