Is the New Microsoft Office Really Open? 511
joesklein asks: "From CNET, there is an article about the new Microsoft Office 11. In summary 'Microsoft says it's opening its Office desktop software by adding support for XML--a move that should help companies free up access to shared information. But there's a catch: It has yet to disclose the underlying XML dialect.' Could this be grounds for another anti-trust suit against Microsoft?"
That's still to be seen... (Score:2, Interesting)
Are we talking about true standard XML is Microsoft going to "embrace and extend" it?
XML... sharp?!? (Score:2, Interesting)
"XML dialect"?!? (Score:4, Interesting)
It's called a schema.
Talk about embrace and extend. Sounds like this will be more "XML-like" than real XML...
My Guess..... (Score:2, Interesting)
You've seen Microsoft generated HTML (Score:1, Interesting)
well, of course (Score:5, Interesting)
Of course it could. But so could any bit of news about MS on
But "could" and "is" are differnent things. I suspect MS will decide that closing XML will render it useless, and make it at least as open and useable as their MS-HTML files.
So, at the worst, we'll have a new "save as" option that's bit sloppy--but since MS won't have to extend XML to get their office functionality, they probably won't do it just to spite a few OSS coders who'll figure it out in a year anyway.
Re:Reverse Engineer (Score:1, Interesting)
I fully expect that this is what Microsoft intends to do. Just because a document is in XML, doesn't mean it has to be readable or writable XML. XML, ultimately, is just a term, and a loose format. It is not a guaruntee that you'll actually be able to interpret and re-write it using notepad or vim.
I have a suspicion that the reason Microsoft set up its next version of Office to be XML compliant is that a few of their customers became interested in Staroffice's idea to do the same thing.
Looks like a case of 'Deliver buzzword to shut them up' to me.
As for whether it's grounds for an anti-trust suit?
Sure, why not.
Will it matter?
Not in 2009, when we might expect the trial to end.
Give me a break... (Score:4, Interesting)
This isn't even intelligent spin from MS. This is fucking brain dead stuff. They simply have no reason to play nice in an industry consortium to agree on a DTD/Schema when they have 90% market share. But as long as they publish the details of their Schema and don't leave chunks of encoded COM schwag lying all over the place it doesn't matter. Of course, we all know the likelihood of that happening.
Proprietary? But of course! (Score:2, Interesting)
This is just a guess, but what if the documents in XML included certain binary CDATA entites that would only be accessable in Office 11 products? That seems like a real no-brainer to me.
But I make this guess by following a file-format from the open source community - PNG (which IE doesn't support). PNG allow you to embed private data - data that can only be opened by certain programs. For Macromedia Fireworks, this works great, as they store all their undo, vector, and export information in one of these private chunks. Yet if you open it with Mozilla or QuickTime, you can still view the image (although the size of the resulting file makes it completely unusable for web).
So it seems perfectly natural that Microsoft would use something similar in Office 11. Make it so anyone can open & read a Word doc, but if you want to truely take advantages of all the wonderful features (hee hee) of the document, such as smart links,
Now, I'm NOT a fan of Microsoft - I hate the fact that every day I'm stuck on their piss-poor operating system/file system/network. I hate the hoops I have to jump through to get things to work in IE. BUT, opening up office documents, even if they don't open them up completely, is well within their rights.
(I'll still use openoffice.org, anyway!)
Re:LOL (Score:5, Interesting)
I'm not kidding, either. Seems like an easy thing to avoid in an HTML generator. Validator [w3.org] routinely reports hundreds of coding errors in simple short documents generated by Word. Ugh. What really sucks is when you're working on a web page for someone and cleaning out all the crap that Word generates, then at the last minute they send you the same document with some minor errors corrected.... and all the same major errors generated by Word. Fun.
This is very simple (Score:4, Interesting)
Re:Reverse Engineer (Score:3, Interesting)
HINT: if you see MS use the phrase "full fidelity" when they talk about their new Office's XML output then you can be sure they're not giving you the data interoperability/portability you thought XML output was going to give you.
Open but Secure (Score:5, Interesting)
Edit this file outside of MS Office (invalidating the hash code) and suffer the consequences: MS treats it as "untrusted" input and rips out only the text content, no formatting.
The hash will be a giant number created through a secure portion of the Intel-ish hardware calls. Keys hidden where? That'll be interesting to see who posts 'em first. Perhaps on a
Curious Curious.
mug
Re:That's still to be seen... (Score:2, Interesting)
XML IS Office 11? Pah (Score:2, Interesting)
Microsoft opening? Naw... Waiting for Palladium. (Score:2, Interesting)
What if they could scrap all that and have an easily read document format? They could tighten integration with IIS -> Office and web pages generated from saved documents, spreadsheets, etc. An XML file format can do it. This would be something MS would like to do.
The problem is XML could be readable by anyone. Or at least it CURRENTLY could. But, what if, MS had a technology to transparently encrypt/decrypt files on the save/read? And, what if the keys to those files were then stored in a protected memory vault that only trusted apps could get to? A trusted nub could ensure that the apps weren't tampered with... You can see where this is going.
As I understand it, with Palladium, MS could declare that the next Word format is PlainText, but documents still wouldn't be able to be opened by 3rd party software, as they aren't trusted by MS to hold the keys to decrypt the data files.
It's a win/win for Microsoft. They get to dump legacy code and create something simpler, while gaining greater control over how people use their own files. It's a win/lose for the consumer, though. They'll get new functionality if they stay all Microsoft, but will be locked into an all/nothing choice of whether they choose the MS route, or not.
THAT, to me, sounds like a typical MS business plan.
Doh! Ah here is the code above was the output (Score:2, Interesting)
<?mso-application progid="Word.Document"?>
<w:wordDocument xmlns:w="http://schemas.microsoft.com/office/word
Re:They Have Too (Score:1, Interesting)
You'll have to ask Microsoft why they hav a suddern desire to switch everything to XML, I have no idea. The current proprietry format is actually pretty clever, it has to be when you consider what can go in there (just about anything).
I'm guessing that Microsoft are viewing this as start of a transition to XML. As I understand the current format, if you copy and paste a CorelDraw drawing into Word at the moment, its Corel, not Microsoft who decide what goes into that section of the Word document. In this case, there is no way for Microsoft to XMLise this part of the document. I've no idea how they're gonna do it unless the dump binary (Base64 encoded?) into the XML. They also need to store the object ID so the Word knows which legacy app this chunk of binary came from.
Don't get confused. (Score:4, Interesting)
Most rational specifications are for performance. The method should not matter as much as the end result. Fire codes are an extreem example, but even there the specification is flexible. The local government does not tell people how to build buildings, only that there needs to be so many exits per so many people and floor space. They don't nail you down to real specifics. Most rational specs are such as mil-specs for acryilic - it must be able to sit in the South Florida sun for one year without delaminating. How you make the thing does not matter, so long as it does what it should.
By these rational and objective standards M$ junk generally fails. If you say that a Word doc should be legible and keep it's formatting for a number of years, Word fails. The same thing can be said of all other M$ junk - it's designed to break and therfore government should reject it's use anywhere records are kept. That's all public work. That's hardly engineering the document, it's simply stating the thing should work as advertised.
All normal standards, from ASCII to WWWC are formed by professional agreement. Governments intervention is not needed. Disruptive vendors are generally seen through.
Re:EXCEL SAMPLE (Score:3, Interesting)
This displays really well as source in Phoenix .5. There is a blurb at the top that says "This XML file does not appear to have any style information associated with it. The document tree is shown below." ... Then it displays it as prettily formatted (though fairly useless) code.
I'd like to see a clean HTML version of the same. It might make it somewhat easier to understand more or less what it is doing
Re:Are you paying attention? It's Microsoft. (Score:3, Interesting)
Crossplatform enough for you?
Oh, you mean edit the files? I remember writing VBA code that did that just fine.. Good documentation how to do that - much easier then working with a crazy-ass XML schema?
So what exactly are you asking for?