[
Lists Home |
Date Index |
Thread Index
]
Hi.
> Mostly agree but I have to ask:
>
> Why would I need XForms for a word processing program?
XForms itself is not quite right for the job but ultimately you need
SOME way of specifying how the user interacts with the content. That
includes:
- how the content looks to the user in the editor
- how edits are done (straight type in text? drop downs? other widgets?
etc)
- how the content is constrained/validated
In MS word world, these are all implicit. If you put a table in your
doc, word gives you the table editing widget set. Word doesn't let you
type in anything that the word document format can't support. Word
makes sure the file you save is in word format.
If another application opens the document, it may mimic word's UI for
editing tables or it may provide its own. That decision is completely
arbitrary, unspecified, and left open to the implementer of the app.
The document can't have data about the editing interface or validation
schema imbedded or linked in it. This is the stone age compared to the
way presentation formatting is handled. Imagine each word processor
interpreting its own ideas about how a document should look when
printed! Should two apps come up with something different we would look
at them as not being cross-compatible. Remember when the browser
decided what p's, b's, and li's looked like? We ended up with site
navigation lost in gif images.
I'm supporting XML end to end in a CMS and this is where the pain is for
me.
I know I've gotten off topic for the original post, which I interpret to
try to address "what semantic information would a document author need
to represent in word processing document format that they can't
represent in XHTML".
I think a similar question is "why use docbook instead of XHTML".
Technically you could use XHTML to represent anything docbook
represents, with the liberal use of naming conventions in the class and
ID attribute values.
I love microformats for simple semantic markup that adds value to
information that is often embedded in web pages to begin with, but I
think trying to turn XHTML into docbook using the same philosophy is a
mistake in practical terms.
The boom microformat (http://www.alistapart.com/articles/boom) is very
close to the edge in my opinion, and I think the shortcomings would
become apparent when you tried to write a real spec for it, do
validation or (to a lesser degree) do complex transforms.
-------->N
>
> 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.
>
|
