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

> 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