Lists Home |
Date Index |
From: Nathan Young -X (natyoung - Artizen at Cisco)
>> 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.
Ah. Then a publishing format standard should include the specification
for it's editor? Is that what you intend?
- An animation format such as SVG or X3D has to have both rendering
and behavior models as part of the standard; otherwise the intent of
the author is lost among implementations. This is true and why X3D
has an object-model based specification with the interchange formats
being multiple and optional. This has actually worked in practice
- Is that true of word processing?
- Is it necessary for a word processing standard to include a
spreadsheet standard or be able to plug one in?
- Should a word processing standard just be a container standard
with plugs for the other formats?
Simplicity? As few formats as possible? Diversity and open markets?
The requirements are in collision and no amount of "la langue de bois"
can cover that up. IMO, the market has yet to wake up to the reality
that procuring this stuff with those goals is going to be very hard. I see
day in RFPs where consultants and customers stack more features into
each iteration of essentially boilerplate requests but we keep discovering
each customer is only using 20% of the features 80% of the time.
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?
2. Does that mean Docbook, ODF, Office 12 only have value for 5 to
10% of the web authors?
3. Does that mean only 5 to 10% of the users are requiring 95 to 90% of
the customers to pay for the development and sustaining costs of their
very small part of the content?
Sounds like a dieing market built on a dead architecture with a
lot of foolish customers.
It took years to convince DoD that they didn't really need 1000 dpi formats.
They said they did because the constraint was not print fidelity alone, but
the amount of information needed on a page where the size of the document
itself was constrained by the amount of warehouse file cabinet space
and the waterline of a weapon-laden destroyer. When shown that this
computer screen and processor weighed quite a bit less, they were
impressed. Then it became a problem of figuring out how to actually
destroy a CD when it was time to get rid of it. Acid worked nicely.
We are caught on the horns of just-in-time bundling that server side
content is supposed to solve. It doesn't seem to me we really need
ODF or Office for much longer and that anyone buying the argument
that openness of either of these creates a market may just be buying
a file cabinet startup.