On 3/11/07, Ben Scott <[EMAIL PROTECTED]> wrote:
On 3/11/07, Jeffry Smith <[EMAIL PROTECTED]> wrote:
> [the backwards compatibility provision in OOXML] ... are all things that
> should be in a conversion program - not a modern data storage format.
I don't think it's that simple, for reasons I've mentioned elsewhere
[1]. Effecting simultaneous industry-wide change is very difficult.
True, but unlike MS, ODF is making the attempt. I'll dig out the
articles that cover how ODF is proper (I believe the term is
"conforming") XML, and OOXML is not.
> Instead, MS has chosen to include all the bugs of every old program ...
That is very common in the IT world. Ibid.
"Just because everyone else jumps off the cliff, you would?" - it's a
great rationalization, it's not a great excuse.
> ... in ways that can't be duplicated by anyone else ...
*THAT* is a big problem.
Groklaw asserts that this standard is full of requirements for
undefined behavior. I have a big problem with any such "standard".
However, for reasons already given [2], I'm no longer willing to put
blind trust in the Groklaw analysis, and I suspect that doing so
actually hurts the cause: We're basing our arguments on shaky
foundations, and ECMA will see that, and dismiss our objections.
ECMA will do what MS tells them to do - they "standardized" Windows
(it's the basis of WINE) - but that "standard" is unusable (to
implement Windows, you need to use a whole bunch of MS functions that
are NOT in the standard - and not defined anywhere). Their charter
for this - "produce a standard identical to the MS submission" - NOT
"produce a standard for office documents."
THAT IS NOT HOW STANDARDS ARE PRODUCED (of course, my ideal is the
IETF method - before an RFC reaches that stage, there must be two
independant implementations that implement ALL the features (including
options) and produce identical results).
> ... in a format that can't be read by the old programs (that don't
> understand XML) ...
This sounds rather like a double standard. You're decrying
Microsoft for maintaining compatibility with old documents in one
place, but here decrying them for not maintaining it.
No, I'm pointing out their reasoning is bogus - they claim it's to be
"compatibile" with all that old stuff - but the old programs can't
read the new file format, so why maintain it? Why not have an
up-to-date standard? If the old data is needed, run it through a
conversion program.
> ... all of which suggests it really is a dump of the MS Office memory.
What else would it be? It has to be based on *something*, and if
you're going to store a document, shouldn't it contain what one has
entered into the program?
No, it should be a proper XML document - a data structure that is
understandable for purposes of office documentation - not a dump of
binary data wrapped in XML headers.
Sure, Excel and 1-2-3 and so on are full of warts and misfeatures
and design flaws, but again, just pointing that out does not justify
rewriting the world from scratch.
Only the data format, not the world. Again, since the old programs
can't read the new formats anyway, there's no loss in converting the
format.
> [Microsoft] just incorporated the old software into the new.
You expect them to just dump everything they've ever written? Many,
ECMA included, will not doubt see that as unreasonable.
I don't expect them to rewrite their software, but the fact that the
only documentation they have is "this is how the code behaves"
explains one reason they are having problems producing the EU required
documentation - they literally DON'T have any idea how it works.
Of course, as I pointed out above, ECMA will do what MS tells them to
do. At least they have so far.
We don't rewrite the Linux kernel from scratch for every major
release, either.
No, but we also document the interfaces.
> Oh and that "optional" bit - it's optional unless you want to say you
> can support the whole standard.
What if I don't want to say that, and just want to say I can read
what you send me? Sounds like a win.
EEE - Embrace, Extend, Extinguish. I guarantee MS will NEVER use the
base standard -they'll always use some of the "optional, & no one else
can read/write them parts" - I've seen the HTML braindamage Frontpage
dumps.
See above for the IETF means of defining standards.
And if I *do* want strict bug-for-bug compatibility, I'm presumably
have legacy baggage that needs such, and so it isn't optional for me,
then, either.
That's what conversion programs do - not data formats.
Footnotes
---------
[1] http://article.gmane.org/gmane.org.user-groups.linux.gnhlug/9217
[2] http://article.gmane.org/gmane.org.user-groups.linux.gnhlug/9213
-- Ben
_______________________________________________
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
_______________________________________________
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
