 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
PoD wrote:
> Governments mandate ISO standards are to be used for documents so that
> they won't be locked into using a single supplier for their software.
If "lay out the lines of text like Word97 does" is important, you're
already locked in.
> MS forces their under specified format through ISO.
Yes, this is bad.
> Because the "specification" of the standard is incomplete MS is the only
> body which can implement it.
Because the standard specifies so much *more* than the other standards.
Obviously, for example, the standard has to specify how to talk to COM
objects, since Word documents can do that. Yet nobody else is going to
implement all of COM just to support that feature, even if it *was*
fully specified, which it can't be in any reasonable way.
> End result - government departments are still locked into using MS office.
But not because of the standard being incomplete, but because nobody
else is going to try to duplicate what the standard would specify were
it actually complete, because you can just go to MS and buy a copy of
Word for a fraction of what that would cost.
I mean, if you really cared what the word wrap algorithm for Word 97 is,
it's not any less precisely specified than the word wrap algorithm for
Open Office.
> As for the "do this like word97", the correct way to handle this would
> have been to include sufficient algorithms in the specification to allow
> a translator to convert old word documents into the new format.
You can. The word wrapping just won't be the same. Which doesn't seem to
be a problem for ODF, since ODF doesn't tell you what the word wrapping
algorithm is either.
> From what I've been reading it seems that MS office won't actually be
> compliant with the ISO version of OOXML anyway so governments should
> refuse to buy it.
Which works great, until you can no longer get out of jail at the end of
your sentence because your government lost all the paperwork. Then
you'll be all like "Can't you just splurge a hundred bucks on Word and
let me free?" :-)
Is there *any* SQL server that actually follows the standard? *I* sure
haven't found one. Better get rid of all the databases the government
keeps too.
It *is* a sucky standard, but that's what you get when you take
something already finished and try to document the details that have
been historically piling up over decades. I suspect it's a good enough
standard that if MS stopped selling Word and you needed to move your
documents to a new format, you could move most of the content to
something else. You might lose some formatting, some active macro stuff,
etc, but probably no worse than trying to move Postscript to LaTeX or
some such.
--
Darren New / San Diego, CA, USA (PST)
"That's pretty. Where's that?"
"It's the Age of Channelwood."
"We should go there on vacation some time."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> "If the changes are made on a server without Excel 2007 installed and
> the resulting spreadsheet is distributed to employees throughout the
> organization, then every single employee will have to get through a full
> spreadsheet recalculation (arbitrarily lengthy) next time they open the
> spreadsheet."
Heck, I have Excel 2000 on one machine here, and Excel 2003 on another,
and I can't even open a 2000 spreadsheet in 2003 without it going
through a full recalculation. And he's complaining that if he *changes*
the spreadsheet, it goes through a full recalculation? :-)
--
Darren New / San Diego, CA, USA (PST)
"That's pretty. Where's that?"
"It's the Age of Channelwood."
"We should go there on vacation some time."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> If "lay out the lines of text like Word97 does" is important, you're
> already locked in.
Only because that algorithm isn't documented. If the algorithm *were*
documented, this wouldn't be the case...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Note that there are no important parts of this standard that are not
>> completely defined.
>
> But that's my point. Are the parts that aren't well-defined in OOXML
> also "important"? Or they just stuff that Word needs to put there to
> make sure that when you export it and then import it again, you get
> exactly the same results?
You know, PDF manages to look the same everywhere. This clearly
demonstrates how "impossible" it is to write such a standard.
>> The trouble is, the M$ standard is something that looks like a
>> standard, but would be really hard for anybody except M$ to implement.
>
> So the complaint isn't with the standard as much as it is with how
> difficult it is to understand or implement the standard?
>
> I hate to say this, but there's all kinds of standards like that out
> there. :-) Especially in the telephone world.
You know, PDF specifies exactly how stuff should look on a page - and
*lots* of people have implemented that. HTML & CSS allow you to
construct complex layouts, and these are also widely implemented.
>> Basically, the way the "standard" is written means that the only way
>> to implement it is to duplicate Word. You can't [easily] implement it
>> in a slightly different way. And that's not the point of standards...
>
> Agreed that the only way to implement all of it would be to essentially
> duplicate every aspect of what Word does. But that's my point. If this
> document standard is a way of storing Word documents, and you want to be
> able to store them and bring them back into Word without change, you
> need to dump to the file every ability that Word has.
That's kind of the point. It shouldn't *be* a way of storing Word
documents, it should be a way of storing documents.
> If you don't want to implement Word97WrapMode in your word processor,
> then ignore that flag, yes?
You make it sound as if this is the *only* Word-specific part of the spec.
>> Of course, a document format standard *already* exists.
>
> It looks like the standard allows you to include arbitrary scripts in
> arbitrary scripting languages. Kind of hard to ensure interoperability.
Yeah. HTML has had this ability for years, and they've had no end of
trouble ensuring interoperability. Oh, wait...
> It also lets you name the fonts without including the glyphs. Again,
> hard to ensure that what comes out is what went in.
Your point? Word's native .doc format has precisely the same flaw. As
does PostScript, actually. And PDF, depending on your settings...
>> And it's pretty
>> obvious why M$ wants to invent another one rather than use the
>> existing one...
>
> Well, sure. Because the existing one can't store Word documents. That's
> kind of my point.
I refute that.
I have converted Word documents to ODF and back again, with little or no
change to the document.
The motivation of M$ is very clear to see here. They want to claim that
because they've documented this "standard", anybody that wants to could
implement it, and hence any data stored in this format isn't locked up
in an unreadable format.
The fact is, this is not the case. Nobody is going to be able to
implement this standard properly, because it is specifically and
deliberately designed to be impossible to implement. And that should not
be allowed.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Darren New" <dne### [at] san rrcom> wrote in message
news:47f6ffc2$1@news.povray.org...
> Is there *any* SQL server that actually follows the standard? *I* sure
> haven't found one. Better get rid of all the databases the government
> keeps too.
There's no database product I've seen that fully and only implements the
SQL:2003 standard, forget the latest one. Most products implement somewhere
between some and most of the standard, then add their own features on top.
It's what makes the idea of 'database portability' such a joke
But then, the latest SQL standard is a mess. That it's not freely available
doesn't help.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Is there *any* SQL server that actually follows the standard? *I* sure
>> haven't found one. Better get rid of all the databases the government
>> keeps too.
>
> There's no database product I've seen that fully and only implements the
> SQL:2003 standard, forget the latest one. Most products implement somewhere
> between some and most of the standard, then add their own features on top.
> It's what makes the idea of 'database portability' such a joke
On the other hand, they all implement more than enough of the standard
that you can write applications that can target arbitrary database engines.
Additionally, there's absolutely no need to scrap database engines when
exporting data from one engine to another is so trivial... Sure, the
database integrity logic and indexes and constraints and so forth are
another matter, but the *data* is easy to get at. The same doesn't apply
to Word...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Orchid XP v8" <voi### [at] devnull> wrote in message
news:47f72f3f@news.povray.org...
> On the other hand, they all implement more than enough of the standard
> that you can write applications that can target arbitrary database
engines.
If you like writitng apps with one hand tied behind your back, that is.
I've tried writing 'database portable code' I'd rather eat glass than do
that again....
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Vincent Le Chevalier wrote:
>> I think the problem is that we should be defining a standard to store
>> text documents, not Word documents...
>
> We have one already. ;-)
>
> Seriously, the only reason this came up is because lots of people are
> using Word, and their governments basically said "You shouldn't be using
> Word, because it's not a standard."
>
Not exactly. Governments were saying that they want their documents to
be readable in the future. Using an undocumented proprietary binary
format won't work. There is no guarantee that any MS product will
support the current file formats in 20 years time, nor that the company
will even exists, nor that e.g. Word 2003 will run on then available
hardware. Hence they decided that from now on, or at least as soon as
possible, data should be saved in a format that is documented.
Governments being what they are, they also decided to artificially
enhance competition by requiring that the standard is public available
and implementable by anyone. Although MS is the most visible target,
more companies have to change their behaviour.*)
There are two major ways in viewing MS attempt at a standard. One is by
looking if it achieves the primary goal of this law. I think it does. MS
documents written in this standard will be readable in 20 years time.
The other one is to take into account the other objective, i.e. to
increase the competition. Then it seems to fail miserably, and by
design. It has been pointed out that this is logical for a company to do
so. I think part of the underlying differences in point of view in both
camps is the familiar division whether companies are bound by the ten
commandments or not (where the ten commandments are short hand for
ethical and law abiding behaviour).
[snip]
>
>> It does not bring any of the benefits a standard should bring.
>
> Right. I'm not saying the standard is good, or should pass. I'm saying
> the arguments against it that I've seen are stupid arguments. :-)
>
They only seem stupid if you disagree with the (hidden) premises of the
speaker. Most arguments are along the line of 'this is not how you
define a standard'. If you think that they should not have been forced
to create a standard in the first place, these arguments may seem void.
*) Personally I can't wait until every medical company will be forced to
save patient data in a format that will make it possible for every
researcher to reanalyze the patient data in an attempt to improve the
diagnostic value. Even if it costs me part of my job security. Just
Thursday I did two minor reverse engineerings of some data files to see
whether I could reanalyze 24 hour ambulatory ECG measurements of
patients and if an ECG recording system was able to record at 8kHz, as
specified, so we could use it for rats too. Answers were yes and no
respectively, but I would have preferred to spend that time on my own
project.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel wrote:
> [snip]
I agree with all that. :-)
> They only seem stupid if you disagree with the (hidden) premises of the
> speaker. Most arguments are along the line of 'this is not how you
> define a standard'.
I primarily mean that most of the arguments seem to be along the lines
of "OOXML doesn't tell me how to X, so it's a bad standard", while ODF
doesn't tell you how to X either. Or "You can't implement everything in
the standard without recreating Word", when what's in the file is, by
definition, everything that Word can do. That's the sense in which the
arguments seem silly to me.
Sure, if your premise is "we shouldn't have to reimplement Word in order
to implement everything in the standard", then such arguments make sense.
I think what it comes down to is, given the standard, the arguments
against it are mostly kind of silly. However, were you to create a new
standard from scratch, you wouldn't put in the kind of stuff that you
need to put into OOXML to make it preserve all the semantics of current
Word documents. And most arguments I've seen confuse these two situations.
--
Darren New / San Diego, CA, USA (PST)
"That's pretty. Where's that?"
"It's the Age of Channelwood."
"We should go there on vacation some time."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New escribió:
> Sure, if your premise is "we shouldn't have to reimplement Word in order
> to implement everything in the standard", then such arguments make sense.
We shouldn't have to reimplement Word to change the value of a single cell.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
