a 'mooh' point

clearly an IBM drone

Hyprocrisy 101

Software politics: Hypocracy 101

Course Title: Hypocrisy 101
Major: Software politics
Points earned: 10 ECTS
Prerequisites: none
Attending professor: Mr. Rob Weir, IBM

Course abstract:

When participating in the ever evolving landscape of software politics you need to master a variety of tools essential to ensure your success and accomplish your goals. This course will give you the ability to master any discussion involving software politics and to blow your opponents off the field

Course contents:

Deny, deny, deny: 5 lessons

Introduction: You will have to be able to deny anything at any place without flinching. Even if your opponent has fact-based arguments, simply dismiss these as either

  1. wrong
  2. from questionable resources
  3. or based on faulty assumptions

Remember, you choose what you want to comment on and you choose which arguments to take. 

You’re fucked either way: 4 lessons

Introduction: Never say anything wrong but also never say anything correct. If you are challenged on something you said, simply take any valid and solid resource and pick something out of context. If you are challenged on this, do one more iteration. Most documents can be interpreted either way, and only your imagination limits you in what you can do. 

Talk is silver but silence is gold: 6 lessons

Introduction: This is tricky to apply in a real-world, offline, discussion – but when applied to an asynchronous discussion on a blog, it works wonders. Whenever you feel challenged or cornered up in a discussion, simply leave for at few days. This will effectively dampen down the discussion and cool everything off. Then come back after a few days and pick up another, more easy, discussion as if nothing happened. If someone complains about you leaving the discussion – simply argue that you have a day-job to do to support wife and kids and bloggin’ is your secondary activity.'

Beat around the bush: 8 lessons

Introduction: Aside from not being concrete on anything, you will have to be able to master appearing to answer a question - when you are really not. A real-world example of a perfect example of this is from the blog of Brian Jones.

Brian Jones said:

You know what Rob, how about if you just take the questions and responses and post them on your own site? You are a member of the US national body and you have access to all of the materials. If it's no big deal, then post them for everyone.

Where to the attending Professor, Rob Weir, replyed:

I wouldn't want to give the Ecma password out, because the Ecma server is already slow as it is, and I wouldn't want to put more load on it.  Best to keep that for NB-access only.

Notice how this should be mastered? It appears that the question is answered ... when really, it's not.

 

With regards to which books and resources will be used throughout the course, feel free to contact the attending professor, preferably on his blog at http://www.robweir.com/blog/ .

Smile!

Yderligere svar fra ECMA

Svarene på de 750 unikke kommentarer fra de nationale råd er nu begyndt at komme i en lind strøm fra ECMA. Seneste udmelding fra ECMA er, at antallet af behandlede kommentarer nu er på 51% og tilgængelige fra det ISO/IEC-kontrollerede website. På seneste udmelding fra ECMA er tillige listet en del af de forslag, som de har valgt at følge. Det er en interessant liste, specielt da de faktisk var valgt at lave nogle ændringer, som jeg i hvert fald ikke havde regnet med de ville ændre. Listen er jo på deres website, men er tilføjet dette indlæg også:

  • Anvendelse af ISO-datoer
    Dette er faktisk én af de ting, som jeg er græsk/katolsk overfor, men det ser ud til, at man nu tillader persistering af datoer i regneark som både ISO-datoer og tal. Dermed gøres det på samme måde som i ODF, hvor man også har valget imellem tal eller datoer (hvilket i øvrigt har gået langt over hovedet på de fleste)
  • Internationalisering af ugedage
    Ét kritikpunkt af OOXML har været funktionen WEEKDAY() i regneark, der ikke tillader angivelse af en uge, der starter på andet end enten søndag eller mandag. Nu bliver det muligt at angive dagen, som ugen starter på
  • Sprog-angivelser
    Dette er så vidt jeg kan huske "ST_Lang-problematikken", hvor angivelse af datoer skulle gøre på to forskellige måder i stedet for at anvende en givet standard. Super!, at de nu bliver fixet
  • Side-kanter
    Angivelse af grafik til side-kanter var tidligere en lukket liste, dvs ikke ret fleksibelt. Nu bliver listen åben. Det er en god idé, da kontrol over dokumentets visuelle layout dermed gives tilbage til brugeren ... og ikke er forbeholdt formatet selv.
  • Formel-grammatik
    OOXML anvendte sin egen måde at beskrive formler, og ikke alene var det ikke en standardiseret måde at gøre det på, den var også mangelfuld. Nu ændres det til at anvende en såkaldt "udvidet BNF-notation". Den tekniske reference for dette er "ISO/IEC 14977:1996 – Syntactic metalanguage – Extended BNF."

Jeg deltog i ECMA-mødet 7. december 2007 og ISO/IEC-plenary 8. december 2007 i Kyoto som repræsentant for Danmark og jeg og de andre repræsentanter for forskellige råd var bla. en del af diskussionerne i ECMA af flere af punkterne herover. Det var rart at høre og få vished for, at de rent faktisk bekymrede sig for vores holdninger til deres rettelser og de spurgte flere gange konkret, om vores respektive holdninger til den ene eller den anden løsning. Det var tydeligt for mig, hvor vigtig godkendelsen af DIS29500 er, og formatet ikke var helligt i dets nuværende form, men at der var en accept af formatet ville blive ændret som et resultat af processen.

Skulle du være interesseret i at se mine egne, personlige, rejseoplevelser, så kig forbi www.ringtilcamilla.dk Smile

What's up with OLE?

A few weeks back I made an article about how Microsoft Office 2007 dealt with password-protection of an OPC-package, since this feature is not a part of the OOXML-specification. The answer I found was that Microsoft Office 2007 persists the password-protected file as a OLE2 Compound File ... more commonly known as a "OLE-file". I also concluded that using OLE2 Compound Files is not a problem - and certainy not an issue regarding OOXML.

Now - the whole topic around OLE has been at the front row of the worldwide debates regarding OOXML. My personal opinion is that the people jumping up and down screaming about problems with OLE ... really haven't understood what OLE is.

So let me start by making a small recap' of what it is really all about.

... there is OLE and then there is OLE 

First of all:

there is "OLE" and then there is ... "OLE"

... or put in another way:

there is the "OLE-technology" and then there is the "OLE-file"

or in a third, more correct, way:

there is the "OLE application technology"  and then there are "Compound Files".

The foremore mentioned is the technology that - on the Windows platform - enables a program to use the UI of another program ... without launching the entire application itself. I mostly use this when editing MS Visio-documents in Word but other usages of this is using an Excel spreadsheet in an MS Word application. The OLE-technology itself is a tool on the Windows-platform that all applications can - and do - use to enable "utilizing other applications in their own applications". It is here important to understand, that there is (today) nothing really revolutionary about OLE. Another similar technology on the Windows-platform is DDE and on the Linux-platform it could be KParts and Bonobo. These technologies simply enable one program to communicate with another (simply put).

But what about these OLE-files?

Well, Compound Files are actually not dependant of OLE-technology. Or put in another way: you don't need OLE-technology to read and use the contents of a Compound File. Compound Files are just files. A Compound File is a collection of persisted streams - actually much like a ZIP-archive. Most commonly it is used because it brings the ability to "utilize a file system within a file". Of course you will need to know how to use the contents of the file, be it created by OpenOffice, Corel Draw, Adobe Acrobat or any application that might store its files using Compound Files. But this is seperate from being able to read and write to the contents of a Compound File.

Ok - I will not bother you any more with this. You should check out the original article about OLE and also look into the specification of the binary formats for Microsoft Office95 - Office2007, avilable from Microsoft. It is actually quite interesting. Just remember that OLE-technology and Compound Files are not the same thing.

And now for something completely different (kindof)

In the lab-tests I have been part of for the Danish Government (National IT and Telecom Agency) we have tested OLE-interoperability. It is important since it is quite normal to embed e.g. a spreadsheet file in a Text-processing file. So it is important that the contents of the file is actually usable when receiving it and opening using another application or on another platform.In this setup we only tested Compound File interop and not interop between OOXML and ODF.

What we did was this:

We created a ODF-file using OpenOffice where we embedded a Excel-spreadsheet (binary .DOC-file) (on the Windows-platform)

We sent this file to a number of different platforms and applications

  • Windows XP using OpenOffice.org 2.3 DA
  • Windows XP using OpenOffice Novell Edition
  • Linux using OpenOffice Novell Edition
  • Linux (SLED) using IBM Lotus Notes 8

We tried to open the file and documented what happened.

#
Setup  What happened? 
1
Windows XP using OpenOffice.org 2.3 DA OpenOffice.org opened the document and correctly displayed the contents of the spreadsheet. It was possible to edit the spreadsheet and save it back into the ODF-container
2
Windows XP using OpenOffice Novell Edition OpenOffice Novell Edition opened the document and correctly displayed the contents of the spreadsheet. It was possible to activate the spreadsheet but only in "read-only"-mode
3 Linux using OpenOffice Novell Edition OpenOffice Novell Edition opened the document and correctly displayed the contents of the spreadsheet. It was possible to activate the spreadsheet but only in "read-only"-mode
4
Linux (SLED) using IBM Lotus Notes 8 Lotus Notes 8 opened the document and correctly displayed the contents of the spreadsheet. When activating the spreadsheet the user was prompted to convert the spreadsheet. When accepting this it became editable and when saving it back into the ODF-container, the spreadsheet was persisted as an Open Document Spreadsheet.


So what we saw was basically 3 different approaches to handling the embedded object. In general the Excel-object (Compound file) itself was not a problem - regardless of application and platform. All combinations had no problems with opening the file and displaying the contents - even on platforms without OLE-technology present. The difference was in the applications and their handling of the object. OpenOffice.org presented the approach that most people would expect: it allowed editing the embedded object and saving it back into the container. OpenOffice Novell Edition allowed activating the embedded object but not saving it back into the container and Lotus 8 took the approach of converting the Excel-object to an Open Document Spreadsheet.

A conclusion?

Well, we took great care not to conclude much - that was not for us to do, we merely provided the technical background for post-lab conclusions. However - the pattern emerging from the description above was similar to a pattern we saw a lot. The problems were not in incompatibility between the formats but instead in how the applications and converters dealt with the formats. We also saw no indications that any of the formats were tied to a specific platform. There were no problems with roundtripping - or to put more clearly: the problem we saw when round-tripping documents were not caused by incompatibilities between the platforms (e.g. Linux and Windows) but between different behaviour in the applications implemented on either platform.

So is this good or bad news? Well, as always, truth lies in the eyes of the beholder ... but I think it is good news. 

Where did my line go?

When we started doing our tests in the lab and started thinking about what we thought we would be seeing, we had a very clear understanding that it would not all be blue-sky conversions and that we would identify problems - some more severe than others. We were also pretty aware, that there would be areas, where conversion was just not possible.

But - I am pretty sure I speak for the rest of the group - we were quite surprised to see which areas this concerned.

On area where absolutely nothing could be converted was ... lines. Not only line art, not only complex line drawings ... but simply - lines.

Lines are done in OOXML as either VML or DrawingML and in ODF it is done using a SVG-derivative. The puzzling thing is, that this area is apparently simply left out in either of the converters. We made some simple documents (line.docx 10,47 kb) and (line.odt 6,60 kb)  [I have re-made these for this article]. When converting these files using CleverAge 1.0 on Microsoft Office 2003 and 2007, Novell OOXML Translator (on Windows and SLED) or IBM Lotus Notes 8 (on SLED), the lines are simply removed. They are not altered, they are not just hidden, they are not moved to a different location in the document ... they are just removed.

This is another example of the overall observation from our tests ... the quality of the converters are simply not good enough today. If you look at the XML in either of the files above, you will see, that even though they look different, they basically specify the same thing (start and end-point for the line drawn), so technically it should pose no problem to be able to do a better conversion.

It is often said, that the main problem with converting from ODF to OOXML (and vice versa) is incompatibilities between the formats. This example is by first glance suporting this argument, but if you dig a bit deeper into the technicality of it, is simply boils down to a problem with bad converters.

Conclusion: The world is seldom black/white ... even if people are trying to convince you so. More often, the world is grey and depressing as a rainy day. 

Vejledning fra IT- og Telestyrelsen

I går eftermiddags offentliggjorde IT- og Telestyrelsen deres vejledningsmateriale for anvendelse af åbne dokumentformater i den offentlige sektor. Hvis du er journalist eller IT-ansvarlig i en offentligt myndighed, så er deres vejledning et "must-read" for dig - den er fuld af værdifuld information.

Se den på http://dokumentformater.oio.dk 

What is a conversion, really?

I have been part of some work for the the Danish National Telecom and IT Agency (IT- og Telestyrelsen). They have coordinated quite a few projects around the country to evaluate the usage of ODF and OOXML and possible problems with co-existance of the two document standards. The website for this work is at http://dokumentformater.oio.dk .

The basic setup for the projects and tests has been:

How does a particular department handle the two document formats and possible conversion between them?

Which problems will arise given their current software install-base?

Is it possible to provide some guidance to the departments regarding which specific features of a document format to avoid since they cause problems?

In other words it has been a rather pragmatic approach based on trying to answer the question: "Why do you experience the problems you see?"

Observations

The first thing we realized during the very first day was something quite crucial:

We were not testing compatibility between two formats - instead we were testing quality of converter-tools and compatibility between the specific format and the internal object model the format is loaded into.

Converter-tools

Both OOXML and ODF are rather immature document formats in the market today since neither of them has a broad market penetration as such. Despite the document count on Google, ODF is not widely used and most people still save their work in .DOC-files -even though they have Microsoft Office 2007 installed. This means that conversion between them is also rather immature and this affects the quality of the converters and the results of converting between one format and another. The ODF-Converter project has an extensive list of the differences between the formats themselves and also a list of features currently not supported by the converter and similar lists exist of features not supported by the other tools used. Luckily it seems that the quality of the converters are drastically improving for each incremental new release.

We also noted that a converter is not "just a converter". It lives and breathes on the application it is installed. This was of particular interest when looking at the ODF-Converter Office Add-In and the SUN OOXML-converter. They are both add-ons to existing Office applications but the application behaviour we saw was in principle the same when using OpenOffice.org, IBM Lotus Notes 8 or OpenOffice Novell Edition.

The problem lies in the fact, that every application has an internal object model that determines how a document is persisted in memory in the application. The binary format for Microsoft Office files were essentially a binary dump of the current memory in the application and this basically counts for at lot of applications with binary file formats. Anyway - regardless of how a document is "converted" or "transformed" using another application than the originator, at the end of the day it has to be loaded into the internal object model for the receiving application. This essentially means, that unless there is a 100% air-tight 1-1-mapping of the document format and the internal object model ... information will be lost. This was one part of the problem - the other was the sequence of conversion. Take a look at the sequence listed here:

Sequence 01  Sequence 02
   
load original format Load original format
 ↓
Convert format to new format Load original format into internal object model
 ↓
load new format into internal object model (make changes)
 ↓
(make changes) Persist as new document format
 
Persist as new document format  

It is not entirely evident that this will produce the same output, and we have seen no evidence that any of applications tested did actually have a 1-1 mapping between (any) document format and their internal object model. This also counts for Microsoft Office and its corresponding file types and OpenOffice itself. In short, this was a fact that we had to deal with in our tests.

On a funny note:

The conversion tools we used were all based on XSLT-transformation between the document formats. They are both XML-formats, so it is a good choice. However, we heard rumours that Novell would dump their OOXML-converter (based on XSLT) and develop their own converter based on the internal object model. It will be interesting to see, if it brings greater quality to the converters.

On a lighter note:

We saw in our tests that using the binary Microsoft Office file format as a middle-man when converting from OOXML to ODF (and back) actually produced the best results ... by a long shot. Having this step and using the binary Office file format as a type of "Lingua Franca", was more or less the key to "flaw-less conversion". If you stop and think about it, it makes perfect sense why we saw this. The Microsoft Office Binary file format is well established in the market (not thanks to Microsoft, but to reverse engineering) and the format has been arround for a long time. Basically, all applications can read it and all applications can write it. But why is this interesting? Well, OOXML is an XML-version of the binary Office file format, so since there are "no problems" with converting from the binary format to ODF, it should be technically relatively easy to convert from OOXML to ODF, since OOXML is a binary version of the binary file format.

It is just a matter of time ... and continious improvement of the format converters. 

Første kommentarer fra ISO/IEC

Det er pudsigt som man kan have ret. I forgårs (18. november 2007) kom de første rettelser fra ISO/IEC. De har udsendt svarende på i alt 19% af det samlede antal. Deres pressemeddelelse kan ses på ECMAs hjemmeside, hvor den kan studeres nærmere. I korte træk er ISO/IEC-editor Rex Jaeschke begyndt at sende de første rettelser ud. Det sker via et website, hvor de enkelte nationale standardiseringsråd har mulighed for at hente rettelserne til deres forslag. Jeg ved ikke, om fx det franske standardiseringsråd har adgang til rettelserne til de danske, men foreløbigt ser det ud til, at det bliver tilfældet. Indholdet på Hjemmesiden er kun tilgængeligt for de enkelte NB'er (nationale råd), men ifølge Microsofts Brian Jones skyldes det ISO-regler, hvor der specificeres, at kommentarer til forslag og svar på disse er et anliggende imellem ISO og de enkelte lande. I Danmark er Dansk Standard og arbejdet i det underlagt nogle begrænsninger i forhold til fortrolighed, så her skal man nok ikke vente for meget information til at begynde med - men så vidt jeg ved er det diametralt modsat i den engelske pendant til Dansk Standard, så måske skulle man holde øje med de informationer, der kommer ud derfra. Eller - deres regler er ret meget lig de danske, men de har valgt en anden tilgangsvinkel i forhold til arbejdet med OOXML, hvor de bla. har anvendt Wiki'er til at indsamle information, og de har også offentliggjort deres kommentarer til DIS 29500 ligesom vi har gjort i Danmark. Igen er valget af format faldet på en wiki.

Jeg har tidligere refereret til ordsproget "May you live in interesting times" ... og mon ikke de er på vej igen?

Smile

Det begynder at ligne noget

Aktiviteten i OOXML/ODF-sfæren er ved at gå op i et højere gear. Bemærkelsesværdigt nok har de fleste af Microsofts OOXML-resourcer været stort set fraværende på deres blogs siden afstemningen i september, men de er nu begyndt at titte frem igen. Man må håbe, at fraværet var været brugt konstruktivt på feedback til ECMA og Rex omkring kommentarerne til DIS 29500.

Alex Brown (ordstyrer til BRM-konferencen i Geneve i februar 2008) har postet et link til en FAQ, der opridser proceduren for afholdelsen af BRM-konferencen. Alex er i øvrigt medlem af den britiske udgave af Dansk Standard. Som Dansk Standard stemte de vist også Nej (med kommentarer) til DIS 29500. FAQ'en er relativt god læsning, så hvis man er interesseret i processen, er den klart læseværdig. Af specielt interessante områder er punkterne om, hvad der ikke bliver diskuteret på mødet samt, hvordan selve mødet vil blive styret. Der er også nogle kommentarer som hele "P-medlem/O-medlem"-diskussionen, som er blevet misforstået generelt over hle linien. Endelig er det beskrevet bestemmelserne for, om en delegation kan "mixe" antallet af deltagere. Der er et øvre loft på 120 mennesker til møderne, og det giver nogle praktiske udfordringer i forhold til antal delegerede fra hvert land.

Læs den ... du kunne jo blive klogere ...

Smile

Latter day saints

Today I stumpled across an interesting article from a member of the Danish association of Open Source Software Vendors, OSL. Apparently Microsoft Denmark and OSL have had some talks about Microsoft joining the association. Theoretically it makes kindda sense not alone since Microsoft has just had two of their licenses approved by the Open Source Initiative. It also seems that OSL has denied Microsoft membership and that they have chosen to made the communication between them public - at least to their members.

Well, the association has some rules to determine if a company can become a member: (my translation)

"...As a member a company or organisation can be accepted who delivers open source related products or services and who wishes to work actively to promote the purpose of the association, herein:

  • suppliers and and vendors of open source solutions
  • developers of open source applications
  • open source software companies
  • open source software system integrators
  • hardware vendors
  • open source software consultants, herein accountants and lawyers
  • vendors/suppliers of support anddevelopment ofopen source software.

As a member a company or organisation cannot be accepted if they, in relation to their application, cannot document to the board that they within the latest fiscal year has has a turnover/revenue of such size that it can ensure full-time employment of more that one employee, subcontractor or freelancer ..."

As you can see, the statutes are rather loose - basically you only need an interest in open source software and be able to employ at least one person on these grounds.

Still, Microsoft has been denied membership. I haven't seen the documentation of the communication - please supply it, if you have it - but from here it seems a rather stupid move by OSL. I'm not really surprised, though, since I have always found the tone of the association a tad too "high-pitch" and selfrighteous. Microsoft has moved quite a bit in the last few years - much of it due to associations like OSL, and maybe this should be rewarded here.

On the other hand - why would Microsoft put their hands into this bee-hive? Is it just a publicity-stunt and a way to demonstrate the hiprocracy of OSL .... or do they have a sincere wish to contribute?

... or is the reason simply that there is so much bad blood between Microsoft and the open source software community, that it has become impossible to find common grounds?

The article I have referred to is in Danish (Mikkel, can I translate it here?) and amongst other things Mikkel says:

Furthermore I think it is sad that the question about Microsoft's admission in OSL is solely based on the disputes about open document standards [...]. With the stability of Linux and user friendlyness from Microsoft, Communism and Capitalism will be able to create new innovative standards to benefit us all. I think OSL should open up instead of isolating themselves.

With the comparison with Communism and Capitalism he nicely sets up the fronts in the trench-war ... but he has a good point.

Smile

Værktøjer, OOXML, System.IO.Packaging

Efter en masse arbejde i de sidste måneder med OOXML i debatter rundt omkring, er turen nu kommet til et par ord om generelt at danne OOXML-filer. Microsoft har frigivet deres understøttelse af OOXML-formatet som en del af Microsoft .Net Framework 3.0 . Det er inkluderet som et nyt namespace i hierarkiet, nemlig System.IO.Packaging. Det er naturlig vis dejligt, at der nu er et helt namespace i .Net til arbejdet med OOXML-filer, men det har desværre den konsekvens, at man skal have installeret .Net 3.0 for at kunne arbejde med det. Har man ikke adgang til .Net 3.0, så skal man have adgang til 3.-parts produkter.

Det første man skal lægge mærke til er navnet på det nye namespace. Det giver nemlig en idé om tilgangsvinklen til anvendelsen af OOXML-filer. Centrum for anvendelsen er nemlig OPC - eller Open Packaging Convention. Så hvis man skulle tro, at man nu skulle til at arbejde med tekstbehandlingsdokumenter eller regneark, så bliver man skuffet. Du skal nemlig til at arbejde med pakkeformatet i OOXML - OPC. 

Nå - men vi skal jo til det

Dannelse af et tekstbehandlingsdokument

Ét af mine kritikpunkter af AODL var jo, at man "kun" kunne arbejde med filer og ikke kunne arbejde med streams. Jeg æælsker streams, så jeg har forsøgt at lave mit eksempel med OOXML som en streambaseret implementering.

[code:c#]

MemoryStream mXml = new MemoryStream();

Package package = Package.Open(<my stream>, FileMode.Create);
Uri uri = new Uri("/jlundstocholm/document.xml", UriKind.Relative);
PackagePart DocPart =
  package.CreatePart(
  uri,
  "application/vnd.openxmlformats-officedocument.wordprocessingml.document.main+xml");

XmlTextWriter writer = new XmlTextWriter(mXml, Encoding.Default);
writer.WriteRaw(@"<?xml version=""1.0"" encoding=""UTF-8"" standalone=""yes""?><w:document xmlns:r=""http://schemas.openxmlformats.org/officeDocument/2006/relationships"" xmlns:w=""http://schemas.openxmlformats.org/wordprocessingml/2006/main"" ><w:body><w:p><w:r><w:t>Hello World!</w:t></w:r></w:p></w:body></w:document>");
writer.Flush();
writer.Close();
byte[] document = mXml.ToArray();
mXml.Close();

using (Stream DocPartStream = DocPart.GetStream(FileMode.Open))
{
  DocPartStream.Write(document, 0, document.Length);
}

package.CreateRelationship(
  uri,
  TargetMode.Internal,
  "http://schemas.openxmlformats.org/officeDocument/2006/relationships/officeDocument",
  "rID1");
package.Close();

fs.Flush();
fs.Close();

[/code]

Kodegennemgang

Det første jeg gør er at åbne et Package-objekt. I mit tilfælde er det på basis af et System.IO.Stream-objekt (my stream), men det kunne også være en simpel filreference. Da jeg skal lave et tekst-dokument tilføjer jeg en adresse på dette (Uri) og danner en PackagePart med denne reference. Hvis jeg ønskede at lave et regneark i stedet, ville det være på nøjagtigt samme måde - men sidste parameter i CreatePart()-metoden er en "ContentType", der skulle ændres til at være til regnearkstypen. Herefter putter jeg via noget stream-gymnastik mit tekstbehandlingsdokument i min PackagePart. XML'en for dette dokument er den XML jeg dannede til eksemplet om den minimale OOXML-fil. Det sidste jeg skal gøre er herefter at definere referencen til den PackagePart, der indeholder mit tekstbehandlingsdokument. Der defineres, at referencen er en intern reference (den kunne også pege ud af pakken) samt hvilken relationstype jeg gerne vil danne. Slutteligt ryddes der op i de oprettede Stream-referencer.

Konklusion 

Hele ovenstående kodeeksempel er jo gennemsyret af selve OPC-formatet - og jeg kan ikke lade være med at tænke: What the fuck? Hvorfor skal det være så svært? Her er AODL-tilgangsvinklen, der er dokument-centrisk - jo noget nemmere at kapere end dette OPC-helvede. Jeg kan godt lide muligheden for at arbejde med streams og ovenstående var sådan semi-sjov at skrive - men helt ærligt? Som udvikler er jeg ikke nødvendigvis interesseret i at kende alle de esoteriske detaljer om OOXML og dens XMl-væsen - jeg vil bare danne et dokument. Det var jo nøjagtigt den måde man tidligere dannede Office-dokumenter på via Office Automation og COM - her skulle man heller ikke vide detaljer om persisteringslogikken ... man skulle blot danne dokumenter.

Jeg har tidligere haft den opfattelse, at én af Microsofts store styrker var/er at udstyre os udviklere med lækre værktøjer, der giver os glæde ved at programmere ... udover selve opgaverne selv, naturligvis. Jeg har også indtil denne artiklel ment, at ODF ville få det svært, da ODF ikke alene skal vinde på desktoppen - det skal også vinde ved os udviklere. Jeg var sikker på, at de værktøjer Microsoft kunne komme med ville slå fx AODL med flere længder. Men det er i hvert fald ikke med denne tilgangsvinkel man vinder os "over", og jeg håber meget, at Microsoft (eller andre) frigiver nogle klasseabstraktionslag til OOXML og OPC, der giver os mulighed for at danne dokumenter som i AODL - og ikke kræver viden om, hvorden det rent faktisk persisteres. Man kan jo passende starte med at kigge i fx klasse-bibliotekerne til dannelse/afsending af emails i .Net (System.Net.Mail.MailMessage). Her er det jo ikke nødvendigt for mig at vide meget om selve mail-formatet for at kunne sende en email. Det klarer klasserne for mig. Måske man kunne blive inspireret her?

Kildekode: OPCCreator.zip (5,39 kb)

Min vurdering (af 5 max mulige smileys)

SmileSmile