I am having difficulty following this discussion.
I agree with the requirements analysis in draft-ash-alt-formats, it's the
conclusion I have a hard time following.
The idea of using PDF as a normative form appears broken to me from every
perspective except producing a document that looks professional.
* The format is proprietary, only Adobe can change it
* The format is patent encumbered
* The format is dedicated to presentation on paper
* Tools to support the format do not support semantic markup
There is an obvious alternative, make use of XHTML, an open standard that is
expressly designed to be non-proprietary and is so widely used that there is
zero probability that the ability to read the documents will ever be lost for
as long as it is possible to read the media on which they are stored.
To repeat: THERE IS ZERO PROBAILITY THAT MANKIND WILL LOSE THE ABILITY TO READ
HTML
There are billions upon billions of documents marked up in HTML. We managed to
decipher the rosetta stone we can decipher HTML. The notion that this will ever
change is silly. If we loose the ability to read XHTML we will have lost the
ability to read the bits on the hard drive as well.
The one problem that XHTML does present is that support for compound documents
with embedded images are not well handled. This is easily solved through the
use of MHTML, MIME encapsulation of HTML documents and attachments. Again the
format is widely implemented and easy to reverse engineer.
The problem people have with moving to XHTML is not that it is a moving target.
It is the idea of change itself.
A standards based, future proof, non proprietary solution to this problem is to
adopt:
* Use of MHTML as the archive packaging.
* Use of XHTML 1.0 as the document encoding.
* Use of a standard IETF defined style sheet.
* Use of PNG encoding for all images.
These restrictions may all be enforced using easily constructed verification
tools. The W3C already has these and would be more than happy to provide them
to the IETF.
Writing 100% compatible HTML is a bit of a pain but nowhere near as much of a
pain as dealing with RFC TXT format which is designed with the built in
assumption of north american paper sizes amongst others.
There is already one standards body that has adopted the HTML approach. The
IETF is not a standards body for document formats, why not rely on one that is?
Meanwhile regardless of which spec the IETF deems to be normative the engineers
will continue to code from the version of the specification that is easiest to
read.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf