Maybe someone can clear this up for me...


It seems either your organization needs the Word97 word break 
algorithms, or it doesn't.

If it doesn't, what's the broughaha about OOXML not specifying what it 
means?

If it does, either Open Office interprets it correctly, or it doesn't.

If Open Office interprets it correctly, what's the problem?

If Open Office doesn't interpret it correctly, you can't use Open Office 
anyway, so you'd be unable to obey the government mandate to use open 
software where available.

It seems like this whole "the spec is underspecified in small ways" 
complaining is just really "we don't want MS to have a standard here 
because the point was to keep people from using MS software."

There's never going to be enough information in the spec to reproduce 
what the software does, or the spec would be bigger than the source code 
of the software.

Something else nobody has answered for me: Does the ODF spec actually 
specify the line breaking algorithms and how they're applied in 
different settings?

(Note: I'm not disagreeing the spec is incomplete. I'm not disagreeing 
that MS has f'ed up the ISO with their party games. But on the other 
hand, is anyone really surprised when something like ISO goes up against 
something like MS they lose?)

-- 
   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

http://ooxmlisdefectivebydesign.blogspot.com/

Looks like he added lots more info. Only this post was available when I 
first saw that blog:

http://ooxmlisdefectivebydesign.blogspot.com/2007/08/microsoft-office-xml-formats-defective.html

...about how hard it is to do something as "simple" as changing a cell 
to have a constant value instead of a formula (a 5-second operation in 
Excel itself).

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> It seems like this whole "the spec is underspecified in small ways" 
> complaining is just really "we don't want MS to have a standard here 
> because the point was to keep people from using MS software."

  The whole idea with a standardized open format is the same as with
any other standard: That anyone can make a compatible implementation
of that standard. This is good for fair competition and disallows
monopolies.

  What Microsoft is trying to do is a PR stunt: "Hey, we support open
standards, we are the good guys." They want to give a positive image
of themselves. If the "standard" is, however, only implementable by
Microsoft, this kind of PR is mischievous. On the outside they look
like they are advocating open standards and fair competition, but in
reality they are only strengthening their own monopoly. They are also
abusing the standardization system to strengthen their own monopoly,
which is the exact opposite of what standardization is for.

  If their format becomes standardized that's a great asset. They can
go to governments and companies and say: "This is *standard*. You should
use this. ISO standardization is a guarantee for quality. And, you see,
our programs are the only ones which fully implement this standard, and
thus you should use our programs and not those other programs which only
implement it partially."

  That's *not* the purpose of standards. That's the exact opposite of what
standards are for. Standards are not a tool to promote monopolies.

  That's what people are complaining about.

-- 
                                                          - Warp

Post a reply to this message

Darren New wrote:

> It seems either your organization needs the Word97 word break 
> algorithms, or it doesn't.
> 
> If it doesn't, what's the broughaha about OOXML not specifying what it 
> means?
> 
> If it does, either Open Office interprets it correctly, or it doesn't.
> 
> If Open Office interprets it correctly, what's the problem?
> 
> If Open Office doesn't interpret it correctly, you can't use Open Office 
> anyway, so you'd be unable to obey the government mandate to use open 
> software where available.
> 
> It seems like this whole "the spec is underspecified in small ways" 
> complaining is just really "we don't want MS to have a standard here 
> because the point was to keep people from using MS software."
> 
> There's never going to be enough information in the spec to reproduce 
> what the software does, or the spec would be bigger than the source code 
> of the software.
> 
> Something else nobody has answered for me: Does the ODF spec actually 
> specify the line breaking algorithms and how they're applied in 
> different settings?

You know what? PostScript is an open standard. Sure, it's not, to my 
knowledge, backed by any official standards body. But there is a written 
technical specification, available for free, and a large amount of 
software supports that standard. (And most of it isn't from Adobe, the 
creator of that standard.)

Identical remarks apply to PDF. Anybody who wants to can implement that 
standard, and lots of programs have done, and they all worth together. 
Not because these programs are "clones" of what Adobe has produced, but 
because they understand the same file format.

Note that there are no important parts of this standard that are not 
completely defined. (There is space for implementors to add their own 
extensions, but everything you need to be able to read and process the 
format is in the specs.)

If you write word processor documents in a *truely* open format, you can 
move it between different word processor applications. You can also (at 
least in principle) run an external spell checker over it, and have all 
sorts of other analysis and processing tools work on it. It's not like 
you're trying to "duplicate Word" by implementing the 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. Things like 
using raw bitmaps instead of XML tags, because that happens to be how 
Word already works internally and it's easier not to change it. Things 
like controlling aspects of how Word displays the preview on screen.

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...

Of course, a document format standard *already* exists. And it's pretty 
obvious why M$ wants to invent another one rather than use the existing 
one...

Post a reply to this message

Orchid XP v8 wrote:
> 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?

> 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.

> 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.

If you don't want to implement Word97WrapMode in your word processor, 
then ignore that flag, yes?

> 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.

It also lets you name the fonts without including the glyphs. Again, 
hard to ensure that what comes out is what went in.

 > 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.

If ODF doesn't specify how text is laid out on a page, and Word does, 
then you can't export Word to an ODF document and have it come out 
correctly.

It's analogous to imagining a word processing standard that doesn't 
specify the fonts, and then asking how you'd make your word processor 
export to that format, yes?

If you need the features of Word, and you want to interact with Word, 
you're going to wind up with a document format that has all the cruft of 
Word in it. If you don't need the features of Word, you don't need to 
use Word, and you don't need to worry about Word97WrapMode or whatever 
might be in all the gruesome poorly-documented bitmaps, yes?

-- 
   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

Nicolas Alvarez wrote:
> ....about how hard it is to do something as "simple" as changing a cell 
> to have a constant value instead of a formula (a 5-second operation in 
> Excel itself).

"Excel 2007 cannot open the file we have manually updated"

Well, no, I can understand that. Excel opens the file, says "Hey, the 
value of the sum of the columns you added up doesn't match when I 
recalculate it, so something must be corrupt in the file."  Seems to 
make sense to me.

(Plus, ODF says this doesn't work anyway, because you corrupted the 
digital signature. :-)

"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."   Well, yeah, duh.  I'm going to change a spreadsheet full 
of calculations, not do the calculations myself, and then ask the 
spreadsheet to open it, and ... what would you expect?

"What this shows pretty clearly is that either we lack the tools, or 
Microsoft does not think we should be doing that in the first place."

Or, maybe, if you're going to edit a spreadsheet that contains formulas, 
you should understand spreadsheet formulas? Or accept the fact that the 
program that does will fix it for you?  I can't even imagine why this is 
a complaint.

Then he complains that if he corrupts every single formula in the 
spreadsheet, then he can't edit it in a way that lets Excel load it 
without recalculating stuff?

* *
Oh jeez. His second complaint is that floating point numbers aren't exact.

* *
His third complaint is "the format is too hard. Whaaaaaaa!"

His first three complaints about the format all consist of "I can't take 
a spreadsheet, make arbitrary changes to it, and expect it to still 
work."  Well, yeah, the point of spreadsheet software is to sync the 
interrelationships between the pieces.

OK, enough.

-- 
   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 a écrit :
>> 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 think the problem is that we should be defining a standard to store 
text documents, not Word documents...

If anyone needs a standard to store Word documents, it's right there in 
Word, just save the file :-) If there are parts of the standard that 
depend on this specific software, you might as well define the standard 
as "whatever Word is able to spit from the file" and be done with it.

As far as I know this is not the case of ODF, PDF, Postscript... Even if 
there are unspecified behaviours, they shouldn't be described in terms 
of what a particular piece of software does with it. But then I've never 
read the specs of those formats either ;-)

In this specific case, someone implementing the standard and discarding 
the parts "doLikeWordn.nnn" is not choosing a behaviour where the 
standard does not say what should happen, or not implementing an 
extension, he is plainly not respecting the standard.

If only Microsoft can implement the standard, it's not a standard, it's 
a file format. It can be the de-facto standard but that's not the same 
at all. It does not bring any of the benefits a standard should bring.

-- 
Vincent

Post a reply to this message

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."

> If anyone needs a standard to store Word documents, it's right there in 
> Word, just save the file :-) If there are parts of the standard that 
> depend on this specific software, you might as well define the standard 
> as "whatever Word is able to spit from the file" and be done with it.

I agree. That's why I was asking why it was a big deal that the standard 
didn't specify how to understand everything Word can do.

> In this specific case, someone implementing the standard and discarding 
> the parts "doLikeWordn.nnn" is not choosing a behaviour where the 
> standard does not say what should happen, or not implementing an 
> extension, he is plainly not respecting the standard.

But does it matter? If you need it to do like Word97 does it, use Word, 
and you're screwed if your government says you're not allowed to. If you 
don't need it to do like Word97 does it, why do you care if the software 
you're using doesn't respect that standard?

I mean, if the standard doesn't say how word breaking works *with* the 
DoLikeWordNN and it doesn't say how work breaking works *without* the 
DoLikeWordNN, then I'd argue you can safely ignore the DoLikeWordNN and 
meet the standard.

Just like the Ada standard says "Behavior X is undefined." That doesn't 
mean that no matter what you do, you're not following the standard.

If "BreakLinesLikeWord97" behavior isn't defined, then it's safe to 
ignore it and still call yourself standards compliant, just like 
whatever code you generate for running off the end of an array in C is 
going to be standards compliant.

> 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. :-)

-- 
   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

Vincent Le Chevalier wrote:
> In this specific case, someone implementing the standard and discarding 
> the parts "doLikeWordn.nnn" is not choosing a behaviour where the 
> standard does not say what should happen, or not implementing an 
> extension, he is plainly not respecting the standard.

Oh, and incidentally, if you *care* whether "doLikeWordn.nn" works, ODF 
isn't going to work for you either. ODF doesn't say how to break lines 
(at least that I could find), so if you *need* the word breaking to be 
in this mode, you *can't* use Open Office or something like that. If you 
*don't* need the word breaking to be right, you can use some converter 
that ignores this flag.

Note this flag is irrelevant to writing a spell checker, a document 
indexer, etc as well, so the argument is kind of silly in that way, too.

-- 
   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

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.

MS forces their under specified format through ISO.

Governments say "OOXML is an ISO standard, lets use it."

Because the "specification" of the standard is incomplete MS is the only 
body which can implement it.

End result - government departments are still locked into using MS 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.

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.

Post a reply to this message

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] sanrrcom> 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

Orchid XP v8 wrote:
>>> 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.

I didn't say it's impossible to write such a standard. But then you've 
also taken away the ability to make it do something differently.

> 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.

Right. But PDF is telling you how to render an already laid-out 
document. You're not going to be able to take a PDF file and (say) 
change the size of the font, and deduce what the layout is supposed to be.

> That's kind of the point. It shouldn't *be* a way of storing Word 
> documents, it should be a way of storing documents.

And that's basically the argument against it.

>> 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.

No, there's lots. I'm just picking that one because it's a perfect example.

> Yeah. HTML has had this ability for years, and they've had no end of 
> trouble ensuring interoperability. Oh, wait...

Yes. Go talk to any javascript author. In spite of javascript also being 
a standard. :-)

>> 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...

Right. So why do people complain that they can't look at the Word format 
and figure out how it's going to wrap the lines?

>> 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.

And did they use the Word97LineBreak conventions? :-)

> 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.

Didn't you just say you converted Word documents to ODF and back again? 
How unreadable could the format be?

This is exactly my point. You can't have it both ways. You can't say 
"Open Office is great because it can read Word documents" in one 
paragraph and then say "Word sucks because nobody can read its 
documents" in the next.

> 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.

It can't be impossible to implement, as Microsoft has implemented it. 
Any part that's not specified is open to interpretation. If the 
word-wrap isn't specified, then any implementation is OK. It might not 
come out exactly like Word, but it's still an implementation of the 
standard.


-- 
   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

Orchid XP v8 wrote:
> but the *data* is easy to get at. The same doesn't apply 
> to Word...


 > I have converted Word documents to ODF and back again, with little or 
no change to the document.

-- 
   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

Orchid XP v8 wrote:
>> 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.

Oh, this only applies to the attributes of the document that are in 
common with ODF. If you want to store the Word document with the 
embedded .NET XML in it that accesses the SQL Server tables to 
regenerate the chart when you open the file, you'll have a bit of 
trouble, I expect.

-- 
   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

Orchid XP v8 escribió:
> Yeah. HTML has had this ability for years, and they've had no end of 
> trouble ensuring interoperability. Oh, wait...

Sounds like you never did anything non-trivial in Javascript in a 
webpage. Or CSS. You can have HTML interoperability nightmares without 
even involving scripts.

Post a reply to this message

Nicolas Alvarez wrote:
> 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.

You do if it's a spreadsheet and that cell is involved in formulas. 
That's what a spreadsheet *does*.

That's like saying "we shouldn't have to reimplement a page-layout 
engine to change a single word in a PDF file."

-- 
   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:
> 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.
> 
I think most people think that MS should not have preserved whatever 
Word does but should have designed a standard for a text document with 
layout specifications. As the old Word files don't conform to the 
standard anyway there is no reason to put everything that is for 
historic reasons in there into the new file. If a government requires 
you to write a 'document file format' that is not the same as 'document 
your file format'. Of course the counter argument is that Word and it's 
files contain much more than just text and markup. Within MS office 
there is no clear distinction between text, webpages, presentations, 
databases, and spreadsheets to name a few. And the counter counter 
argument is 'indeed'.

Post a reply to this message

"Orchid XP v8" <voi### [at] devnull> wrote in message
news:47f72f3f@news.povray.org...

> 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...

Ever tried getting data out of a database file (any product) when you don't
have access to the DB engine that created it?
Good luck.

At least if I open a word doc in notepad I can copy the info out. The
formating's gone, but that can be replaced.

Post a reply to this message

Gail Shaw wrote:

> Ever tried getting data out of a database file (any product) when you don't
> have access to the DB engine that created it?
> Good luck.

OK, yah, that's not even funny...

Post a reply to this message

> You know, PDF manages to look the same everywhere. This clearly 
> demonstrates how "impossible" it is to write such a standard.

Ermm, no, I have seen several PDF files with forms and buttons etc that only 
work properly in Acrobat Reader.  I guess they are using Adobe specific 
extensions that nobody else implements.

> You know, PDF specifies exactly how stuff should look on a page - and 
> *lots* of people have implemented that.

Word (and PDF to a certain extent) allow you to do far more than just say 
how it should look when printed or print previewed.

> HTML & CSS allow you to construct complex layouts, and these are also 
> widely implemented.

But usually look slightly different on almost every browser!

> That's kind of the point. It shouldn't *be* a way of storing Word 
> documents, it should be a way of storing documents.

Sure, then just ignore the Word specific stuff and parse the document data 
to display.  But when you export form Word that extra data is there should 
you wish to implement certain things that Word does.  If MS only exported 
exactly what you saw there would similar outcry about how it is impossible 
for developers to implement the same functions as Word.

> I have converted Word documents to ODF and back again, with little or no 
> change to the document.

That's because you've only been using the "basic" features of Word, which is 
fine.  But some people might want to develop programs to work with the more 
advanced features of Word, previously they couldn't - now they can, but they 
don't have to.

> 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.

"Implementing the standard" is not a digital yes no thing, you can implement 
just the parts you need for your application.  As Darren said, if you wanted 
to implement the whole standard perfectly you'd essentially have to write a 
copy of Word.

Post a reply to this message

> "Implementing the standard" is not a digital yes no thing, you can 
> implement just the parts you need for your application.  As Darren said, 
> if you wanted to implement the whole standard perfectly you'd essentially 
> have to write a copy of Word.

Let's say we have small app A and B.
If app A doesn't implement parts of the standard they don't use,
and app B doesn't implement parts they don't use,
then chances are you will have incompatible files between app A and B.
This incompatability is what standards are meant to help avoid.
Adopting a standard that is difficult to implement doesn't help
A and B, but it will help MS.
MS will be able to load files from A and B,
and save them in a format that is not readable by A or B.

Post a reply to this message

> Let's say we have small app A and B.
> If app A doesn't implement parts of the standard they don't use,
> and app B doesn't implement parts they don't use,
> then chances are you will have incompatible files between app A and B.

Why?  If app A and app B did nothing in common (so no parts of the file were 
implemented in both programs) then why should the files be compatible?  App 
A might be a simple word processor with no support for images, App B might 
be a utility that cuts out all the text and just leaves you with the images. 
Nobody would expect the files from App A to do anything useful in App B.

> This incompatability is what standards are meant to help avoid.

Which it does.  It says that if you are going to include text, you do it 
like this, if you are going to put in an image, you do it like this, etc. 
If your App A doesn't need images, you just ignore those parts in the file, 
and if you're writing App B, you better make sure you implement the part of 
the spec that deals with images.

> Adopting a standard that is difficult to implement doesn't help
> A and B, but it will help MS.

Sure it helps A and B, in the past they wouldn't be able to write these 
programs without reverse engineering the .doc file type.

> MS will be able to load files from A and B,
> and save them in a format that is not readable by A or B.

Why should the file saved by Word not be readable by A or B?  A and B will 
just ignore the parts they don't need.

Post a reply to this message

Tim Attwood wrote:
> If app A doesn't implement parts of the standard they don't use,
> and app B doesn't implement parts they don't use,
> then chances are you will have incompatible files between app A and B.

Then why is everyone using XML?

Answer: because it's easy to ignore the parts you don't use.

-- 
   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ó:
> Then why is everyone using XML?

Hype? :)

Post a reply to this message

> Why should the file saved by Word not be readable by A or B?  A and B will 
> just ignore the parts they don't need.

Because you are choosing a situation that fits a best case for
the standard. Let us say that A and B are both word processors,
to the end user of A it makes sense to load up a document that
has the same extention as documents produced by A, even if
they came from B. Now lets say that A uses VML and B
uses DrawingML, the document from B probably will not
look right in A, even though both programs will claim to be
ISO compliant (but are only partially). At the same time MS
will be able to load documents from A and B and save them
using special MS markup that neither A or B understand.

Post a reply to this message

>> Why should the file saved by Word not be readable by A or B?  A and B 
>> will just ignore the parts they don't need.
>
> Because you are choosing a situation that fits a best case for
> the standard. Let us say that A and B are both word processors,
> to the end user of A it makes sense to load up a document that
> has the same extention as documents produced by A, even if
> they came from B. Now lets say that A uses VML and B
> uses DrawingML, the document from B probably will not
> look right in A, even though both programs will claim to be
> ISO compliant (but are only partially).

Well sure, but that's just how standards work.  If program A or B only 
partially implement the standard then you cannot expect them to open every 
possible file and show it correctly.  And we don't expect people to 
implement every single part of the standard, because then you're rewriting 
Word!

If your application A only uses VML, then I would expect the developer to 
include some converter to put images into VML format.  Otherwise he must 
expect a lot of people to get annoyed because he hasn't implemented the 
other common image types.

> At the same time MS
> will be able to load documents from A and B and save them
> using special MS markup that neither A or B understand.

Well fine, but it ceases to be an ISO OOXML file then if any program puts in 
stuff that is not in the spec.

Post a reply to this message

> Well fine, but it ceases to be an ISO OOXML file then if any program puts 
> in stuff that is not in the spec.
Isn't that why people don't like the new standard?
MS put their custom tags into the ISO standard so they can
avoid rewriting Word to be ISO compliant. It's easier for
MS just to change the standard. A and B now need to re-implement
Word just to be ISO compliant, the standard is useless in this
regard. It doesn't specify a single "best practice" it gloms
together bits of dissimilar methods into a single standard.
It's a wart on a wart on a wart, and warts are ugly.

Post a reply to this message

>> Well fine, but it ceases to be an ISO OOXML file then if any program puts 
>> in stuff that is not in the spec.
> Isn't that why people don't like the new standard?
> MS put their custom tags into the ISO standard so they can
> avoid rewriting Word to be ISO compliant. It's easier for
> MS just to change the standard. A and B now need to re-implement
> Word just to be ISO compliant,

Well there's a surpise, you invent a new standard to define Word documents 
in an open way, then you complain that to read them completely you need to 
re-implement Word!

> the standard is useless in this
> regard. It doesn't specify a single "best practice" it gloms
> together bits of dissimilar methods into a single standard.

As far as I can see, it simply allows other programs to read and create 
files that are compatible with Word very easily.  I don't think anyone is 
going to attempt to implement every single feature of the real Word.  And I 
guess the reasons that governments want it is so that if MS suddenly decides 
to do something stupid (very unlikely) then other programs will be available 
to easily get the data.

Post a reply to this message

scott wrote:
> Well there's a surpise, you invent a new standard to define Word 
> documents in an open way, then you complain that to read them completely 
> you need to re-implement Word!

And if MS didn't do this, then people would complain when they use the 
advanced features of Word that they paid for because they need, and then 
they can't open the file again after they saved it.

> And I guess the reasons that governments want it is so that if MS 
> suddenly decides to do something stupid (very unlikely) then other 
> programs will be available to easily get the data.

It'll also be helpful to avoid the whole "what secret stuff is MS 
leaking into my documents" kind of MS-added-an-NSA-cryptokey complaint.

-- 
   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:
> 
> It'll also be helpful to avoid the whole "what secret stuff is MS 
> leaking into my documents" kind of MS-added-an-NSA-cryptokey complaint.
> 

That's assuming MS is not going to add plenty of non-standard tags in 
their own implementation...

What will you think of a big binary blob between tags bearing the very 
explicit name <newUndocumentedTag3425543>  :-) ?

-- 
Vincent

Post a reply to this message

Vincent Le Chevalier wrote:
> Darren New wrote:
>>
>> It'll also be helpful to avoid the whole "what secret stuff is MS 
>> leaking into my documents" kind of MS-added-an-NSA-cryptokey complaint.
>>
> 
> That's assuming MS is not going to add plenty of non-standard tags in 
> their own implementation...
> 
> What will you think of a big binary blob between tags bearing the very 
> explicit name <newUndocumentedTag3425543>  :-) ?

I think it'll probably be unnecessary for you to parse it in order to 
(a) follow the standard and (b) get reasonable results.

Why, what do *you* think would happen?

-- 
   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

> What will you think of a big binary blob between tags bearing the very 
> explicit name <newUndocumentedTag3425543>  :-) ?

Try deleting out that section and see what happens?

Post a reply to this message