DSSSL-lite (according to my current understanding) does indeed try to that,
and certainly does a better job than some other suggestions that have come
down the pike.
However, the task hiding under the phrase "marrying form with content" is the
core of the difficulty. One reason is that the relationship between form and
content is inherently thorny (witness the history of philosophy :)), but the
more pragmatic reason is that people disagree on both the nature and
importance of each. To a graphic artist, form is all that matters. I do some
freelance graphic design, and if I put up a WWW page containing promos or
samples of my work, they're going to be completely form-oriented (probably
Acrobat with font embedding). On the other hand, my sister-in-law with
retinitis pigmentosa doesn't care about form--she only cares if her screen-
reading software can translate a web page into speech. I cannot see a
practical way to satisfy both sets of criteria in a single representation.
Rather, I think that multiple representations are called for. In my
hypothetial graphic-oriented page, I could have a textual description (for
disabled or bandwidth-impaired folks), images (for Acrobat-impaired folks :)),
and the "real" versions. As a content provider, I would rather have a browser
tell me what formats it prefers, and send it a document constructed directly
for that level of abstraction, than to try and construct a "universal"
document and have to test it with every available browser to make sure it
looks right on each. Netscape's extensions are already bringing us perilously
close to this state of affairs.
> However, I see many WWW pages being created with graphic headlines
> and images because of the limitations according to the
> current specification. Content providers are pushing for more
> control over the form of their message and I think it is to
> everyone's advantage to give them more control. At the same
> time, browsers of the web should still be able to view the documents
> in plain text format.
I agree completely. I think that this is a fine motivation for beefing up the
support for multiple representations in browsers, servers, and if necessary
HTTP itself. I think that trying to expand HTML to encompass everyone's needs
is doomed to failure. People want to do arbitrarily complex things, and so
something that purports to be universal will by necessity become arbitrarily
complex.
> Now, since I'm unfamiliar with the ISO ODA framework you speak of,
> I'm not sure if or why it isn't being incorporated. Someone with
> more knowledge on that matter will have to address it.
Well, it's not backward compatible with current practice (although given the
alignment with SGML it might be possible to define an SGML-style encoding
instead of ODIF, which is based on ASN.1 and BER). It would be verbose, but
it is the best approach to trying to put structure and presentation into the
same document that I've found yet. Unfortunately, as a result it's complex,
and thus has not seen wide deployment except in specal purpose applications.
I don't know if it's possible to do a profile of ODA that would fit current
HTL or not, but it's certainly something I'd be interested in seeing
investigated. Since I happen to have a copy of IS 8613 (the ODA standard) on
my shelf, I'll even put my money where my mouth is and take a look at it this
weekend. I'll report back next week with some more detailed comments.
> Well, some great things have come out of ad-hoc groups ;). But, if
> you have strong input, then you should definitely contribute.
That's why I've jumped into the discussion after lurking for a while :).
Amanda Walker
InterCon Systems Corporaton