[
Lists Home |
Date Index |
Thread Index
]
Hi.
(Len, apologies in advance for butchering your post in my response,
please yell if I've changed your meanings by re-contextualizing)
> On the other hand, there are existence proofs
> for using HTML for high end publishing.
If you use XHTML for publishing a book you may not get a reduction in
complexity. If your book is a novel, you probably need a subset of
XHTML and it might work out fine... but at the same time the semantic
structure of a novel is much closer to the semantic structure of a
textbook. Textbooks have enough complexity and structure and are
different enough from web pages that shoehorning them into XHTML has
costs of its own.
> Is that the
> right level of complexity for the majority of word
> processing given, as a poster stated on Scoble's blog,
> that it doesn't have 5 to 10% of the features of a
> word processing format? (The point is to deliver to
> the end user only as much functionality as they need
> for a task to keep the complexity low and costs
> commensurate.)
The tighter a document format is focused on a specific use, the simpler
it can be. Part of the reason that word processing formats are so
complex is that word processors are used for all kinds of things that
aren't word processing.
> From where I sit, Bray's namespaced thought experiment
> makes sense. Always has. Structural editors make
> sense. Always have (been doing this a long long time).
I agree they make sense but I really don't think we have them yet.
So far one of the "advantages" of standardizing a document format is
that the more documents you have in that format the more money you can
justify putting into developing features for the monster application
that edits that format and the more (ostensibly) that app is worth.
This leads (historically if not inevitably) away from modularity and
away from a tight semantic fit between the document format and its
intended use.
Another advantage of standardizing a document format is
interoperability. Politics and open standards have big effects on this.
Does modularity? Is it an advantage to interoperability to have one big
do-everything format or a bunch of little purpose built formats?
> If I don't want spreadsheets, I don't want the spreadsheet
> editor. I might want a renderer because I can't control
> what people send me. I might only want a spreadsheet
> editor occasionally.
If you support modularity in any kind of extensible way, you quickly
move from having "a document format" to supporting structured content
with arbitrary content models in an extensible way.
To move to this model my assertion is that you have to specify certain
things about the content format in a way that allows the application to
deal with it. You have to specify:
- how it looks on screen
- maybe how it looks in print
- what content model is valid for the format
- maybe how the editing experience looks/functions
----->N
>
> None of this seems mysterious or provocative. What is
> questionable is if the argument that having open formats
> guarantees a market. Having an open containerized format
> might but as in the example of DoD, when the technology
> changes or the environment changes, the market model changes.
>
> So when comparing ODF and Office, one might want to compare
> them for the cost of initial installs and just-in-time upgrades.
> I sort of doubt the Massachusetts Senate and/or executive
> branch think in those terms. The ITheads can. But both should
> understand costs. Monocultures not only expose the user to
> viral risk and can restrict access to public information, but
> they are lousy at cost control.
>
> len
>
>
> From: Robert Koberg [mailto:rob@koberg.com]
>
> Bullard, Claude L (Len) wrote:
>
> > If it is as claimed that HTML/XHTML only has 5 to 10% of
> the features
> > of word processing:
> >
> > 1. What is the world's largest publishing medium (the web)
> so successful
> > using only 5 to 10% of the features of word processing?
>
> I sense a logical fallacy (not really sense it, just have experienced
> it). It is not that only 5-10% are used, it is that 5-10% are made
> useable by the software that allow publishing to web. Blog
> entries are
> not the be all and end all...
>
> This is why I said that the battle is for useable 'write'
> programs. The
> web doesn't have it yet. I would also say that desktop pub systems
> dont't either, but...
>
> When an organization matures in its web publishing there are
> needs for
> more structure (and, of course there is a need for freeform). When
> structure is needed it is welcome as it saves the user time
> and resolves
> confusing choices. There is also the need to be able able to change
> templates/style and not use drones to do it.
>
> I would not want to see what I think you are proscribing. I
> want to see
> a good WYSIWYG, schema validating editor that can choose between
> different content types (FAQ, Callout, Gloosary-Item, whatever) and
> allows for a free-for-all content type.
>
> Content pieces should be separate. They should be able to be placed
> where needed in whatever presentation.
>
> (Our CMS, http://livestoryboard.com , has that now except I want
> something that is more usable for those accustomed to
> MSWord). Xopus is
> the best available currently. I wish there was better and cross
> browser/platform.
>
> best,
> -Rob
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>
>
|
