[
Lists Home |
Date Index |
Thread Index
]
Mostly agree but I have to ask:
Why would I need XForms for a word processing program?
Again: how useful is it to discriminate between hypermedia
and word processing formats? This digs to the heart of
a debate that has raged in publishing and hypertext systems
from the earliest days. If you dare to do less and you
want fewer XML languages, you have to solve this. Else,
there is no inflection point for OpenDoc and Word Doc
remains the standard by de facto adoption.
BTW: HTML as noted by Koberg's URI to Bos and Lie et
al is as you note, a fine printing format. Is that
all a word processing system has to be in a common
core?
What I am on about here is what is the common core?
Else, what other specs and standards should be considered?
Is this really just OpenDoc vs MSDoc, or is this about
Web 2.0 (bleaach) generation applications that rely on
standard components delivered just-in-time such that
the inflection point is about neither of these wp
formats but about the next generation of software in
which there is no useful discrimination between the
desktop apps and web apps other than the communications
plumbing and that comes gratis.
Design here. Legal politics elsewhere.
len
From: Nathan Young -X (natyoung - Artizen at Cisco)
[mailto:natyoung@cisco.com]
If we're talking about a document format to replace MS word documents,
we need much more than XHTML. XHTML holds the content of the document
and provides (some) semantic information about that content. To
replicate what a word doc can do and does do for most users, you have to
also specify how it's going to display and probably provide some
information to the application about how the editing experience should
be presented.
So maybe XHTML + CSS + XForms could do it.
I'm not sure what I would gain by limiting myself to XHTML. Simple
documents are fine in XHTML, possibly with some number of (possibly
partially intersecting) embedded microformat conventions. But to use
XHTML to represent the semantics of a complex document is burdensome
compared to a purpose built schema.
I'm delighted with CSS. There are definitely times when display
requirements can't be satisfied and I need an intermediate XSL
transformation as well, but that's usually when the final output isn't
known at authoring time, and no word processing document format that I
know of deals with the unknown any better.
Put all this together and my ability to use XML in the CMS and transform
it for display is something I'm quite happy with. The really big
barrier right now is my inability to send XML out to users and have them
edit it in a way that grants both of us sanity. XForms is exciting but
incomplete and poorly supported. If anyone has an end-user (read: "good
looking and dummy proof") authoring solution they are happy with let me
know because I'm super motivated to find something.
|
