Another issue raised by IBM and by standards and OSS lawyer Andy Upgrove is that the OOXML specifications would require the implementers to also implement propriety formats and methods of Microsoft that are not licensed under the OOXML licensing.
Andy mentions in his blog post "The Contradictory Nature of OOXML" several issues from the OOXML spec like 6.2.3.17 "Embedded Object Alternate Image Requests Types" refrencing WMF files and 6.4.3.1 "Clipboard Format Types". Further down he mentions for instance OLE embedding and macro/scripts. It is of course correctly seen that the OOXML spec mentions these thing in the specifications. But does it mean that implementing these feature is required if you implement OOXML ?
No of course not.
Firstly, as I have already mentioned in an earlier post, when implementing OOXML you are not required to implement any parts other than stated in the conformance paragraph. You can leave out anything you want.
Secondly, even if you create a FULL implementation of OOXML then still you do not need to implement these features as these references are all references to external formats that are therfore not a part of OOXML. They are references to fully optional formats that you can embed just like you can embed image formats or other media formats.
Thirdly, implementing external formats is is something that is application specific and is not limited to MS formats. You can in fact embed any propriety or open format into OOXML files. OOXML only uses some of the mentioned references to distinguish between format types so you can differentiate between an embedded image file and an embedded windows meta file or a clipboard file. A method to distinguish between foreign file types however is not the same as adding the external format to the spec. If it would, than if a simple line in the spec states "filetype:picture" it requires support for all picture formats in existence ???
Fourthly, you can embed the same formats that are mentioned in OpenDocument also. ODF has about 6 methods of embedding external foreign file formats in ODF files. You can embed the same Windows Meta Files or clipboard file formats just as easy in ODF as you can in OOXML. You can use macro/scripts in ODF and, yes, even even use OLE linking/embedding of external file formats in ODF. Mayby Andy should have complained about ODF supporting all of those formats as well during ISO standardisation of ODF. Especially the fact that Sun, next to regular external object embedding has managed to add specific embedded java objects to ODF (§9.3.4) seems quite weird.
Basically the opponents of OOXML claim that embedding foreign files is fine for ODF but it isn't fine when files are embedded in OOXML because then Microsoft should have licensed those formats even though it might be about exactly the same files.
Is that either highly hypocritical criticism or just ignorance ?
I think I know the answer to that...
Subscribe to:
Post Comments (Atom)
6 comments:
I think you're missing the point.
OXML allows you to insert RTF directly in a document, and doesn't tell you how to read it. ODF allows you to reference other file formats, but doesn't let you import stuff directly like that.
Not exactly sure what part of OOXML you are referring to. See something with rtf in paragraph 11.3.1 but that describes application specific import+conversion support for all kind of formats and also seems to refer to embedded files.
Btw, you can find how to read the latest version of RTF here:
http://www.microsoft.com/downloads/details.aspx?FamilyId=DD422B8D-FF06-4207-B476-6B5396A18A2B&displaylang=en
I'm referring to the "Alternative Format Import Part".
It's not like embedding an image or something; an AFIP can be in the footnotes, or a header, or simply the main document.
If you use them, the end result is basically a document which will not look the same, or even open properly, in other suites. Yes, you can attempt to read the formats they prescribe, but you're not likely to do as good a job as Office 2007.
I don't think anyone cares that Office 2007 will convert those types of files; it doesn't make much sense for it to be part of the "standard" when implementing it is basically going to involve reverse engineering how other apps display those formats.
I see the alternative format import having multiple formats other than rtf.
It is fistly stated as an implementation specific item.
Secondly it is not just rtf but any format, also html or xml.
Thirdly it seems to require conversion to OOXML for rendering.
Fourthly the examples show it to be embedded files trough the relationships file.
It does require conversion to ooxml rendering so to implement it you need a converter for every alternate filetype you wish to support similar to embedden object that require a rendering engine for each filetype supported.
I guess you can actually use this to alternativly import ODF into OOXML as long as you have an ODF converter.
Zridling, why don't you mention what those errors are, instead of making blanket statements and unfounded doomsaying? I've been a part of indirectly supervising several efforts to implement open office, and open source technologies in third-world-countries, and they've all miserably failed for lack of support, just to go back to Microsoft technologies. What you're saying makes no sense at all. OOXML has not proved itself? Wow, I guess the billions of documents out there that applications adopting OOXML can read don't count. Me? I'm thankful MS is finally opening the Office formats. My firm will be able to make some very cool improvements to our technologies for document management, and the fact that it's a standard will only bring us more business, a lot of it from governments around the world who just needed to hear that magic word to avoid having to spend millions switching to another truly unproved platform.
A standard that works as a container
is not worth the paper it is written on.
(includes .odf to some extents)
A good example of a file format with those problems is .avi (granted, not a standard)
Dan
Post a Comment