[
Lists Home |
Date Index |
Thread Index
]
Which is fine for someone who can do all of that and doesn't mind.
Other shops do mind. Good of the many pertains here. Good of the
one is not compromised.
1. This thread is centered around the Commonwealth of Massachusetts'
policy to pick a specification to be their standard word processing
format. This isn't about what one guy does in his own shop. Think
scale and cost.
2. This thread picks up on messages and positions that
taken together make the decision in item one worthy of discussion.
a) There should be fewer XML languages, or don't reinvent the wheel.
Some of us are wheel inventors and enjoy that. Item one above is
essentially the same as saying, "fine if you like to invent and
sell train tracks but if you want to hook up to the city transit
system, they have to be this gauge."
b) Given a), the debate turns to the question of the 'best
language for the job' because experience is that the wisdom
of crowds ain't always that reliable when it comes to choosing
a technical format for one job. No size fits all.
c) Given b), the question is 'what is the job?' and that is hard
to answer without requirements. The crowd doesn't always do the
job. Many of the arguments against the Commonwealth choice center
there: the cost of retraining, the cost of conversion, and so on.
You might summarize those by asking, if there are to be fewer,
what is good enough to be the one? Likely the one the most
people are using today if one thinks the wisdom of crowds works
for a format they are all using rather than deciding for one
job they don't all do. That is XHTML. Neither OpenDoc nor
OfficeXML have the reach of XHTML.
Notice I didn't talk about 'open' once. Why? Because one discovers
if one is honest that what is open becomes what is open enough, not
what is good enough. PDF was open enough. OOXML wasn't. Will it
be now? That is debatable. Is OpenDoc? Most assuredly. Is it
good enough? Given improvements in accessibility, possibly yes.
Should it become a legislated standard for the Commonwealth?
It can be. Are there benefits? I look for cost benefits but the
case isn't in. On the other hand, it will help the market to become
more open, and that is the kind of decision that Senators and
Governors do make on behalf of their citizenry or against them.
Let the aware voter decide if this is important to them.
So this is one part a technical question but that technical question
is easily mooted by diluting arguments based on the scoping values
of privilege, local autonomy, and simply, "so much smarter". The
questions of market power and openness are not subject to that
dilution. The easiest way to keep a monopoly or a dictatorship
alive is to hold competitor's heads under water until they stop
breathing. The only way to break that grip is to change the rules
of grasping.
There is nothing subjective about that.
len
From: Uche Ogbuji [mailto:Uche.Ogbuji@fourthought.com]
I don't know why I'm even bothering with such a hopelessly subjective
debate, but since everyone here seems to be so eager to crown XHTML for
office formats, I'll pip up and say say:
Thank GODDESS for the OO XML project, Microsoft's partially reformed
Office XML format team, and all others who are saving us from the abject
horror of having to contemplate XHTML as an office file format.
Are you kidding me?
All arguments for XHTML everywhere eventually boil down to arguments
that rather than
<monty>
<python/>
</monty>
I should write:
<div class="monty">
<span class="python"/>
</div class"monty">
No bloody thank you. Freedom from naming-by-committee is what drew me
to XML in the first place. I am not about to chuck that freedom for the
very false comfort of a protean generic identifier.
And when I hear people preaching that people should stop writing new XML
vocabularies, I just wonder who's been passing out the XHTML
+Atom-is-all-you-need Kool-Aid.
I'll use XHTML for Web content, ODF for documents of more typical
front-office style, Atom for Web feeds and information that is extremely
easy to mistake for a Web feed, XBEL for links and Web resource
directories (not XOXO-cum-XHTML, not OPML, not even Atom), and so on.
I have great tools and technologies such as RNG, XSLT, Schematron and
more to manage diverse formats, and I see no reason to wallow in a
narrow markup dungeon.
|
