Lukkede dele og binære referencer

Ud fra din beskrivelse ovenfor, så er der ikke noget problem specifikt for OOXML i forbindelse med OLE objekter som sådan. Men det at referere til 3. parts programmer i dokumenter er et helvede at åbne op for i forbindelse med interoperabilitet. Og her gør det ingen forskel om det er OOXML eller ODF, siden de begge har "featuren".

Hvis en person har embedded sådan et objekt i et ellers åbent-format dokument, så vil dokumentet reelt ikke længere være interoperabelt, da man både skal være i stand til at forstå hovedformatet, men også det embeddede format.

Det er helt sikkert at de færreste brugere (udenfor dette forum) vil være i stand til at se konsekvensen af at embedde et eller andet tilfældigt objekt i det dokument de sender til det offentlige. De kan kun se at de bruger det program de har fået at vide, og så er alt jo i skønneste orden. Fru Jensen der skal sende en ansøgning eller andet dokument til kommunen vil ikke kunne se at hun faktisk sender noget som de ikke vil være i stand til at åbne. Og så kan hun ellers have brugt nok så meget ODF eller OOXML.

Jeg vil tro at myndigheder som skal til at modtage dokumenter fra "almindelige" mennesker i ODF eller OOXML bliver nødt til at tage den slags problematikker med i vejledningen, for der er altså elementer af standarderne, som ikke egner sig til dokumentudveksling.

Et godt eksempel på misbrug af denne funktionalitet er MSO's implementation af RTF[1], som blot består i at danne krævet header for et RTF dokument, og så indlejret hele dokumentet i et OLE object i DOC format.

[1] RTF er et dokumentformat opfundet af MS, som i sin tid var deres bud på et interoperabelt format, da det funktionalitetsmæssigt var laveste fællesnævner for et dokument i de forskellige kontorpakker på daværende tidspunkt.

Så nej - OLEObject-elementet er ikke et eksempel på "binær legacy".

Jesper, du har jo netop lige beskrevet det modsatte. Din pointe må være at de indlejrede binær legacy data ikke begrænser sig til Windows platformen?

It should be clarified that OLE technology is not required for conformance nor implementation of the OOXML specification and [b]usage of OOXML documents[/b]

Lige præcis her må OOXML-T vel siges at være dumpet.

Brugen af OOXML er jo ikke blot også oprettelse af dokumenter, men også modtagelse og videreredigering.

Ja, de mener at begge formatter ikke skal være pålisten til dette er blevet rettet. Det tror jeg udmiddelbart ikke at der er nogen som vil modsige dette, da argumenterne imod det er ret godt underbygget.

Ja, de mener at begge formatter ikke skal være pålisten til dette er blevet rettet.

Principielt set så er problematikken der opstår pga. embeddede objekter en ting der burde diskvalificere formater. Men i praksis vil det give alt for store problemer at sætte sådan en begrænsning, da det i andre sammenhænge er en pænt anvendelig feature.

Man bliver nok i stedet nødt til at kigge på andre løsninger for at sikre at embedded objects ikke går hen og ødelægger gevinsten ved at få åbne standarder ind i det offentlige. Det vigtigste må være at det er dokumenteret hvad man skal undgå når man vil sende et dokument til det offentlige. Step 2 må så være at have en whitelist af programmer, som korrekt sørger for at embedde et snapshot sammen med embeddede objekter.

Jamen hurra! ... så endte vi altså med Ø (den tomme liste)

yups :) Man kan ikke sige at OOXML ikke skal på listen pga. OLE, men på samme tid sige at ODF skal være på listen. Sarkasme og v2 rocks :D

Hej Jesper,

Din formulering rammer nu meget godt det som jeg forstår ved binær legacy.

At der er funktionalitet i OOXML, der ikke er beskrevet i specifikationen, men hvor man skal have fat i specifikationen for de binære dokumentformater for at bruge den, eller hvor en funktionalitet i OOXML kræver forståelse for, hvordan de binære dokumentformater er skruet sammen.

Embedded indhold passer fint ind i den beskrivelse, eksempelvis et Visio objekt.

At ODF har samme konstruktion, ændre jo ikke på understøttelsen af indlejrede data i OOXML. Det er da meget positiv såfremt denne konstruktion er den eneste der tillader binær legacy i OOXML.

"Embedded objects" er indenfor funktionalitetsloftet.

Funktionalitetsloftet defineret i Devoteams rapport kan ikke være det samme som funktionalitetsloftet omtalt i konklusionspapiret, idet Devoteam referere til proporitærer teknologier der ikke er forenelige med en åben standard. Mig bekendt er funktionalitetsloftet ikke endnu defineret. Formegentlig bliver det OIO udvalgets ansvar.

Hvis kravet om interoperabilitet skal give nogen mening, skal funktionsloftet undlade indlejrede objekter eller klart definere hvilke indlejrede objekter der indgår inden for funktionsloftet. Selvsagt er det kun åbne formater der kandidere hertil for interoperabilitet skal være muligt.

Mvh
Carsten

Mener du hermed, at da både OOXML<S+T> og ODF har denne mulighed - så skal ingen af dem forefindes på listen?

Hvis ikke ODF har mulighed for at gemme filer på en måde der sikrer, at der ikke er indlejrede objekter i dokumentet, så mener jeg at der er et stort problem med ODF specifikationen.

Det er i den sammenhæng for så vidt ligegyldigt om de indlejrede objekter er binære eller beskrevet i et markup-sprog som resten af ODF- eller OOXML-dokumentet.

Det afgørende er for mig umiddelbart om de indlejrede objekter også er dokmenterede i en åben specifikation.

Så er der faktisk kun ét format tilbage, som sikrer en ordentlig dokumentudveksling. Og det er OOXML-S.

Nu er der bare det, at OOXML-S endnu ikke eksisterer i flere uafhængige implementeringer, så selvom det kommer på listen, kan det ikke bruges.

Tilbage står så ODF og OOXML-T. Der kan vist ikke herske tvivl hos andre end dig og Jasper om, at ODF er det eneste af disse formater, der sikrer øget konkurrence.

En del af B103 http://www.ft.dk/dokumenter/tingdok.aspx?/samling/20051/beslutningsforsl... nævner jo

med henblik på at fremme konkurrencen

Og så lige et par ord om din debatform med først at komme med tekniske forklaringer på, hvorfor Microsoft's format løser alle problemerne, og derefter, når der bliver påpeget mangler, at henvise til at "Sådan gør de jo også i ODF, så de er da ikke bedre". Den har vi set så mange gange før, at det er ved at ligne et mønster.

Men ville det ikke være relevant at sætte et hegn omkring hvilke filformater der må indlejres, hvis standarden skal overholdes ?

Eksemplet beskrevet ovenfor med RTF, kunne jo tyde på at en sådan begrænsning er nødvendig for at undgå at nogen skyder genvej ?

Poul-Henning

Hej Jesper,

der er binær legacy i ODF, fordi man kan indlejre et JPEG-billede i et dokument, men JPEG-specifikationen er ikke en del af ODF

Det er jo utvivlsom noget sludder. Det er nu heller ikke det jeg fremføre.

Man kan godt vælge at sige indholdet i indlejrede objekter er uden for scope ift. OOXML. Det er bare på bekostning af interoperabilitet.

Det må da være rimelig indlysende at en klup vilkårligt defineret data ikke kan forstås, eller vises, af nogen der ikke kender definitionen.

Joeh - men hvordan skal denne white-list udarbejdes? Skal filens indholdvære OASIS/ECMA/W3C/ISO-standardiseret? Skal formatet være Royalty-free at implementere?

Det er da simpelt. Definer eksplicit hvad der er tilladt i stede for at lave et skraldespandselement, hvor man, efter forgodtbefindende, kan smidt hvad som helst ind i.

De er velkendt at denne type fleksible skraldespand-designs, eller sandkasse-designs om du vil, ikke skaber andet end problemer.

Jeg vil minde om, at målet er at sikre frihed for borgerne til at vælge software og sikre interoperabilitet på tværs af implementeringer.

Hvis et givent Dokument ikke er klart valid/invalid er det ikke en dokument-standard.

Som PHK skriver så kan man løse problemet ved skive i standarden hvad der må være i dokumenterne ? (må der f.eks. være JPG? svar ja/nej)

Hvis det Jacob siger er rigtigt så må det gælde begge standarder ?

Da man altid bør løse et problem der hvor det er opstået bør begge standard komiterene-kontaktes så de for rettet op på "rodet" selv. (Det gør man inden for safety-standarder)

Man kan sige at Hanne Agersnap havde ret da hun påpegede problemet med "kontorpakken". (office 2010) (ikke OOXML) Dette blev så bare behændigt misforstået af Jesper.

Hvad der overrasker mig er at dette gælder for ODF også. (Jeg havde troet at ODF komiteen var mere konsistent)

Er det stort nok til, at du vil gøre noget ved det? ODF 1.2 er jo i offentlig høring, så vi hører meget gerne fra dig i DS-udvalget.

Jo tak, jeg vil da meget gerne komme med nogle forslag. PHK er inde på noget af det rigtige, men som du selv skriver, så er det jo lidt problematisk med en whitelist.
Derfor vil jeg foreslå en række kriterier som et objekt skal opfylde før det kan optages på whitelisten over objekter, der kan indlejres i et ODF-dokument.
1. Objektet skal være dokumenteret i en åben tilgængelig specifikation. Det skal være muligt at implementere denne specifikation uden at skulle betale royalties og formatet skal være patentfrit.
2. Der skal eksistere en Open Source implementation af en editor for objekter af den indlejrede type. At det skal være en Open Source implementation sikrer, at objektet kan redigeres på andre platforme end den, hvor objektet oprindeligt er oprettet. Herunder platforme, der ikke er understøttet af producenten af det program, der har frembragt det oprindelige objekt. Desuden medvirker dette krav til at sænke barrieren for andre implementationer af ODF eller implementationer på andre platforme end den, hvor det oprindelige dokument blev oprettet, for at kunne fremvise og redigere det indlejrede objekt.
3. Ønsket om at få objektet optaget på whitelisten skal være offentliggjort inden afslutningen af en høringsperiode, hvor der kan fremsættes forslag om optagelse af nye typer af objekter.
4. Efter at være optaget på whitelisten kan specifikationen for objekttypen ikke ændres indenfor den pågældende version af ODF.
5. Et ODF dokument, der indeholder et objekt fra whitelisten vil ikke blive betragtet som et gyldigt dokument ifølge ODF version n, såfremt det indeholder objekter der først er blevet optaget på whitelisten til ODF version n+1 eller indeholder objekter i en version, der først blev godkendt på whitelisten til ODF version n+1. Dokumentet vil dog betragtes som gyldigt dokument ifølge ODF version n+1 såfremt alle andre kriterier for version n+1 er opfyldt.

Jeg vil lige poste listen her og se, om der kommer yderligere forslag (eventuelt fra mig selv), inden jeg sender forslaget afsted. Jeg går ud fra, at det skal oversættes til engelsk og indsættes i den ISO kommentarformular, du indirekte linkede til. Såfremt det er den formular, jeg skal bruge, kræver det ydeligere hjælp. Jeg forstår ikke de syv kolonneoverskrifter.

1. Whitelisten skal ikke være en del af ODF, men ODF skal referere til den. Dette sikrer, at samme whitelist kan anvendes af OOXML.

Jesper,

OOXML<S> har nøjagtig samme feature. I den bruges blot DrawingML til at tegne den ramme objektet vises i. I OOXML<T> bruges VML til at tegne rammen.

Jeg har absolut intet problem med at OOXML<S> indeholder elementer der er defineret i DrawingML eller at OOXML<T> indeholder elementer der er defineret i VML. Eneste krav er, at disse ikke er lukkede formater, og at der eksisterer Open Source implementeringer af dem. Hvis den ovennævnte whitelist bliver til noget, så kunne det fremover være et krav, at DrawingML og VML fandtes på listen.

Så hvis dette er den eneste anke mod OOXML<S>, og DrawingML er et åbent format, så mener jeg stadig at OOXML<S> ville være en værdig kandidat, såfremt der fandtes implementeringer af formatet.

[b]Og det mener jeg stadig ikke, er tilfældet[/b] selvom Jasper og nu også du giver udtryk for at OOXML<T> er "hele OOXML"

Hvis man sætter sig ned og skal lave sådan en liste (der også skal virke i den virkelige verden), så begynder problemerne at tårne sig op meget hurtigt. Jeg arbejdede personligt i Geneve sammen med delegationerne fra Brasilien, Portugal, Canada og (vist nok) Tyskland på at lave en lignende øvelse omkring multimedie-indhold, og det endte i absolut ingenting.

Det beyder strengt taget kun at den opgave er større end den kan klares imellem worksessions i travlt standardiseringsmøde.

Hvordan greb i det an?
Hvor langt nåede i?
Fortsætter i arbejdet pr correspondence?
OOXML eller ODF only - eller for begge?

I applikationer der understøtter standarden for objekter til indlejring, skal der komme en advarsel ved indsættelse af objekter, som ikke er en del af whitelist-standarden.

På den måde bliver brugeren gjort opmærksom på, at det ikke er tilladt at indlejre det valgte objekt, for så overholder dokumentet som helhed i dokumentstandarden.

Jeg synes dog, at det skal være muligt at indsætte objekter, som ikke er på listen, da der kan være mange situationer, hvor dette kan være gavnligt.

Claus Agerskov, SALDI

Hej Jesper,

Tak for oplysningerne om offentlig høring. Det kommer lidt bag på mig, hvis det er rigtigt, at der er deadline i dag. Der stod jo i den announcement, du linkede til, at "This review period will conclude on March 26th."

Er det en deadline, DS har sat for at videreformidle forslag? Og hvis det er, og DS står fast på den deadline, vil det så være formålstjenligt at sende forslaget direkte til Mary McRae eller Rob Wier?

Jeg vil under alle omstændigheder først forsøge at sende forslaget til Maria Banck-Hammerum og se, om hun vil sørge for videre behandling.

...men at man skulle lade det være op til den enkelte leverandør at vurdere, hvilke formater, man ville understøtte.

Så kort kan det siges.

Hej Jesper,

Jeg har nu sendt forslaget til Projektkoordinator Maria Banck-Hammerum.

Det indeholder nogenlunde de 6 punkter ovenfor, dog med indarbejdelse af Claus Agerskovs forslag. Og forhåbentlig uden alt for mange meningsforstyrrende fejl i oversættelsen til engelsk.

Jeg har sendt kommentarerne både som ODF og DOC, da min OOo ser ud til at have lavet slemme ting ved tabellerne. Og der er ingen udbydere af Office til mit OS ;-)

Hej Jesper,

Er der nogen grund til, at du netop fremhæver OOXML, når nu ODF har nøjagtig samme begrænsninger/muligheder? Er du også enig i, at dette betyder "farvel til interop. i ODF"?

Ja, bloggen omhandler OOXML.

Netop fordi ODF og OOXML har denne type funktioner til rådighed og fordi funktionsområdet i øvrigt er stærk varierende fra format til format, er funktionsloftet så vigtigt at få defineret på en passende vis.

Interoperationalitet er den store "show stopper" ift. det frie valg af software og platform.

Jesper,

Interoperationalitet er den store "show stopper" ift. det frie valg af software og platform. [quote] Jeg er helt enig - men er det et reelt problem? Det er ekstremt sjældent, at jeg oplever problemer med indlejrede objekter - hvad er jeres erfaringer?

[/quote]
Det er også meget sjældent, at jeg har oplevet problemer. Det skyldes jo nok, at behovet for at indlejre objekter, der ikke er dækket af dokumentstandarden, ikke er særlig stort.

Derfor vil det nok også kun være i få tilfælde, at man vil blive generet af en advarsel om, at man anvender objekter, der ligger udenfor standarden. Hvis der så samtidig eksisterer en whitelist med objekter, der ikke skal advares om, så vil problemet være endnu sjældnere forekommende for brugeren, der indlejrer objekter.

Dit forslag er nået frem

Jamen, så takker jeg for opfordringen. Og tak til PHK for idéen.
Og du skal være velkommen til også at bruge forslaget i WG4.

Hej Jesper,

Jeg troede egentlig at du havde fået forslaget igennem DS? Som jeg skrev til Maria Banck-Hammerum, er I yderst velkomne til at rette op på indholdet, hvis der er dele, I vurderer vil være svære at få igennem hos ISO. Og hvis I ønsker at rette sproglige fejl, så vil jeg også tage det særdeles positivt ;-)

Her følger så forslaget, som sendt til DS:

Create a whitelist of object types, that ODF implementations would be expected to understand. Add an attribute to the document, that tells whether the document contains embedded objects of types that are not on the whitelist. In order to be accepted on the whitelist, object types are required to live up to the following requirements: 1.The object must be documented in an open specification. This specification shall be possible to implement royalty-free and the format must be patent-free. 2.There must exist an Open Source implementation of an editor for objects of the embedded type. This requirement ensures, that the object will be editable on platforms other than the one, where the object was originally created. Including platforms that are not supported by the creator of the program, that created the original object. 3.The application to have an object type included on the whitelist must be made public prior to the conclusion of a “public review” period. 4.A new version of an object type from the whitelist is subject to the same requirements as the original version. 5.An ODF document shall not include objects, that are not on the whitelist without clearly stating this fact. And a program that implements ODF shall clearly warn the user before saving a document with objects not on the whitelist if the document originally contained no objects that were not on the whitelist. 6.Optional – The whitelist shall not be a part of the ODF specification, but shall be referenced in the specification. The reason for this point is, that the whitelist could possibly be shared by more ISO document formats. Specifically ISO29500 OOXML.

Som du kan se af punkt 5, er det punkt blødt meget op i forhold til punkt 5 i denne tråd. Blandt andet på baggrund af Claus' kommentar. Men faktisk er det endt med at blive langt mere liberalt. Nu handler det blot om at give brugeren besked om at der er indsat et objekt, der ikke er på whitelisten. Og forslaget starter med at forslå en angivelse af, om et dokument indeholder objekter, hvis type ikke er på whitelisten. Idéen hertil er tyvstjålet fra OOXML (conformance="strict").

Hej Jesper,

Jeg er helt enig - men er det et reelt problem? Det er ekstremt sjældent, at jeg oplever problemer med indlejrede objekter - hvad er jeres erfaringer?

Jeg har oplevet problemet i Word bl.a. ift. Visio objekter. Word er i stand til at vise en hel objekter såfremt den pågældende software er installeret.

Hvad brugeren nogle gange ikke ved, et at modtagerne er ikke i stand til at se pågældende objekter, hvis ikke samme software er installeret påmodtagernes computer. Jeg har selv lavet den fejl og er af samme grund hold op med at bruge indlejrede objekter.

Det er da bestemt ikke hverdagskost, men når det sker, kan det gøre et dokument værdiløst, idet lige præcis det objekt præsentere et central begrebs- eller forklaringselement ift. dokumentets formål.

Både ODF og OOXML tillader referencer til ting udenfor selve pakken...

Ak ja, stort rødt kryds i Word. Hvis jeg altså husker korrekt.

Hej Jesper,

Jeg tror du misforstår noget. Der er forskel på linked og embedded objects.

http://office.microsoft.com/en-us/word/CH063563251033.aspx

Indlejrede objekter er en del af dokumentet. Data ligger inde i dokumentet og ikke i en ekstern fil.

Hej Jesper,

Kan du be- eller afkræfte nedenstående gælder for OOXML?

[b]Linked objects[/b] When an object is linked, information is updated only if the source file is modified. Linked data is stored in the source file. The destination file stores only the location of the source file, and it displays a representation of the linked data. Use linked objects if file size is a consideration. Linking is also useful when you want to include information that is maintained independently, such as data collected by a different department, and when you need to keep that information up-to-date in a Word document. When you link to an Excel object, you can use the text and number formatting from Excel, or you can apply the formats supplied by Word. If you use the Word formats, you can preserve formatting when the data is updated. For example, you can change table layout, font size, and font color without losing those changes once the object in the source file is updated. [b]Embedded objects[/b] When you embed an object, information in the destination file doesn't change if you modify the source file. Embedded objects become part of the destination file and, once inserted, are no longer part of the source file. Because the information is totally contained in one Word document, embedding is useful when you want to distribute an online version of your document to people who don't have access to independently maintained worksheets

Teksten er taget fra overstående link.

Hej Jesper,

Min pointe er, at man som bruger godt kan regne ud at en ekstern fil, som ikke gives med når man videregiver et dokument, ikke kan vises.

Hvis man derimod indsætter et "objekt" i et dokument og derved kan betragte dokumentet som en selvstændig helhed, er det dog ikke mere selvstændigt end modtageren skal have installeret tillægs software for at kunne se "objektet".

På den måde må man betragte funktionen i "Linked Objects" og "Embedded Objects" som væsentligt forskellig.

Jeg kan godt se at "Embedded Objects" er smart. Det er bare også et væsentligt aspekt ift. interoperationalitet. En pegepindsfunktion er af en anden karakter ift. interoperationalitet.

Hvad ville du gerne have Word skulle gøre i stedet?

Det var faktisk ikke ment som en kritik af Word, men en kritik af brugerens manglende omtanke. I dette tilfælde er det jo brugeren[1] der ikke har sikret sig at modtageren har [b]adgang[/b] til det linkede objekt.

Word gør sådan set det eneste rigtige ved at lade beslutningen være op til brugeren. Og der kan jo sagtens være brugsmønstre, hvor linkede objekter er mere relevante end indlejrede.

Men når det drejer sig om hvilken type objekter, man kan linke til eller indlejre[2], så har brugeren ingen hjælp til at finde ud af, om det er sandsynligt, at modtageren kan fortolke objektet korrekt. Og det er denne hjælp, brugeren vil få ved at lave en whitelist.

Så det er to ortogonale problemer, hvoraf kun det første er løst tilfredsstillende.

[1]Brugeren har blandt andet været mig selv indtil flere gange. Og mange gange med mig selv som modtager, når man lige skal arbejde videre på et dokument hjemme.

[2]Du har helt ret i, at forslaget ikke skelner mellem linking og embedding, og det skal det sådan set heller ikke. Men jeg havde ikke tænkt over at whitelisten skal gælde [b]både[/b] linking og embedding. Det må du meget gerne sørge for at få præciseret inden I eventuelt sender forslaget videre i systemet.