> 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

> 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