Djævlen ligger i detaljen

I forbindelse med mine forberedelser til den Stooore interoperabilitetstest af ODF og OOXML som vi i CIBER forbereder, sad jeg den anden dag og legede med regneark. Jeg kiggede på hvordan én af de større kontorpakker gemmer fraktioner af sekunder i en regnearkscelle og opdagede en lille pudsighed.

Værdien, der blev persisteret, var eksempelvis

0.45657843849593335

Men standarden foreskriver, at

The decimal separator shall be a full stop (period), and fractional seconds shall be expressed with no more than three decimal places

Hvis du nu sidder og leder efter en passende reaktion, vil det nok være

#WAT ?

Årsagen til at de decimalpladser er kommet med skyldes et ønske fra de ansvarlige for standarden, der har ønsket at lave et passende minimum for interoperabilitet. Man har ønsket at signalere, at "hvis du ikke bruger flere end tre decimalpladsers nøjagtighed, så kan du være sikker på, at andre kontorpakker kan behandle de regneark du anvender - uden fejl". Jeg er er dog helt sikker på, at man ikke har ønsket at kræve, at der maksimalt må bruges tre pladsers nøjagtighed og aldrig mere.

Det frustrerende er, at lige præcist denne del ved jeg positivt har været tærsket igennem af en række internationale eksperter og det er uforståeligt, hvordan det er gået til, at denne fejl har sneget sig igennem.

For det er jo en fejl. At kræve at fraktioner af sekunder kun må gemmes med 3 decimaler er helt tosset - for det gør det bla. umuligt at bruge et regneark til at beregne tidsmæssige forskelle med andet end "børnehaveklasse-nøjagtighed".

Så løsningen er umiddelbart at ændre teksten i standarden til dette:

The decimal separator shall be a full stop (period), and fractional seconds should be expressed with no more than three decimal places

Dermed sikres standardgivers mål om anvendelse af et minimum for interoperabilitet, men sikrer samtidig, at skulle man i en kontorpakke have krav om større nøjagtighed, så har man mulighed for at gøre det ... uden at ens dokumenter dermed bliver invalide og ikke overholder specifikationen i standarden.

Jeg har forgæves søgt at finde en morale i dette, men jeg er sgu lidt på bar bund. At sige at "det er svært at lave standarder" er lidt let købt, ikke?

:o)

Jesper Lund Stocholms billede
Jesper er seniorarkitekt hos projectum Aps i Værløse og arbejder med PPM-løsninger baseret på Microsoft Project Online. Jesper blogger om softwareudvikling og IT-politik

Kommentarer (18)

Jacob Nordfalk

Med fare for at jeg har misforstået det hele, skulle der ikke stå:

fractional seconds shall be expressed with three or more decimal places.

Jeg tænker umiddelbart at det er svært af formulere sig utvetydigt?

Jesper Lund Stocholm

Med fare for at jeg har misforstået det hele, skulle der ikke stå:

fractional seconds shall be expressed with three or more decimal places.


Jo - og dette udsagn er næsten ækvivalent med det jeg foreslog.

"Problemet" med dit udsagn er, at hvis jeg nu vil gemme "et halvt sekund", så skal det med din formulering persisteres som

0.500

.. hvilket er lidt mystisk, hvis du spørger mig. Konsekvensen vil være, at langt de fleste anvendelser af dokumentformatet vil producere principielt set invalide dokumenter - selvom indholdet semantisk er klart for enhver, der kigger i den bagvedliggende markup.

Jeg tænker umiddelbart at det er svært af formulere sig utvetydigt?


Det er præcist pointen :o). Hvis man ønsker én og kun én opførsel af applikationerne, så er det ligetil ... problemet opstår, når man vil signalere en "intention". Man har også værktøjer som "noter" eller "eksempler" i standarderne, men disse er ikke-normative og kan ikke bruges til at udvide udfaldsrummet for beskrevet funktionalitet - kun til at klargøre det.

Jacob Nordfalk

Ah ha haaa, det med at repræsentere 1/2 sekund, den så jeg ikke.

Men dit forslag:

The decimal separator shall be a full stop (period), and fractional seconds should be expressed with no more than three decimal places

... er også problematisk, da jeg læser det som som man ikke bør gemme mere end 3 decimaler.

Hvad så med

fractional seconds shall be expressed with three or more decimal places. Less decimal places can be allowed, if they are zero.

Jesper Lund Stocholm

... er også problematisk, da jeg læser det som som man ikke bør gemme mere end 3 decimaler.


Men dette er faktisk præcist intentionen.

Spørgsmålet er så, hvordan man indenfor standardens tekst giver mulighed for at gå videre end teksten som udgangspunkt bestemmer.

Når man laver ISO-standarder, er der et meget veldefineret vokabularium, som man må bruge. Dette skyldes at alle skal være enige om, hvad de enkelte ord defineres som. Disse er alle beskrevne i ISO Directives Part 2.

Vi er nødt til at spørge os selv, hvad vi ønsker at signalere. Hvis vi ønsker at sige "brug 3 eller gå amok som du lyster", så kan vi bruge "can", hvor definitionen af dette ord er én af følgende:

The verbal forms shown in Table H.4 shall be used for statements of possibility and capability, whether material, physical or causal.

  • be able to
  • there is a possibility of
  • it is possible to

Ønsker vi derimod at sige "Vi ser helst, at du bruger maksimalt 3 decimaler, men hvis du har et specielt behov, så brug flere", så er det korrekte ord "should", der har definitionen:

The verbal forms shown in Table H.2 shall be used to indicate that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others, or that a certain course of action is preferred but not necessarily required, or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited.

  • it is recommended that
  • ought to

... så djævlen ligger bestemt i detaljerne :o)

Mark Gjøl

Eller evt:
"The decimal separator shall be a full stop (period)."

Det lyder som om den næste del kun giver problemer. Hvis tre decimaler er for lidt, så op til 10 decimaler (eller hvor meget der nu er behov for), men det lyder på mig som om de tre decimaler bare er skudt ved siden af, og reelt ikke vil bruges til noget. "Højst tre decimaler, eller mere" er en informationsløs sætning.

Jesper Lund Stocholm

Eller evt:
"The decimal separator shall be a full stop (period)."


Og dette kunne man så beskrive i et XML schema. Men dermed ville der ikke være nogen guidance til implementationer om, hvordan interoperabilitet bedst sikres.

Og det er jo i øvrigt en hel fin tilgang til problemstillingen, hvis man ikke ønsker det.

Én af de emails, der har fløjet rundt i forbindelse med den fejl jeg opdagede bringer jeg lige i udpluk her:

Yes, I think "should" is certainly necessary unless we want to add a lot more text and content to the standard, as well as make schema changes.

Although [...] is of the view that more precision is better, that is only true from an intra-application perspective, not an interop perspective.

In terms of financial applications and standards concerning finance, it is common to specify levels of precision within the standard – so you assert the level of precision the value is being stored in perhaps an element or attribute related the value. That way one knows whether the value is exact, or could be already be subject to rounding errors, even at the source.

For example XBRL encountered many issues coming from inconsistent levels of precision, which was addressed by adding a precision attribute IIRC.

See this document: http://www.xbrl.org/RFC/PDU/PWD-2008-10-09/PDU-RFC-PWD-2008-10-09.html

Applications will need to be mindful of dealing with values carefully and not entering into a precision arms race as [...] seems to favour.

For example 1,000,000.00 may be exactly that – applications that take that value and then store it as 1,000,000.000000 are incorrect, since it relates to cash transactions and there is no such thing as a microcent.

Although these examples are not date/time specific, they are illustrative.

I did find some useful information from an old communications spec:

" Standards developers shall make provision for receiving systems that require less than six digits of precision in the Fractional Second component to ignore any unneeded trailing decimal places without adversely affecting interoperability. (Explanatory note: A receiving application entity that represents Time values with low precision shall not return error messages to a sending application entity that represents Time values with higher precision.) "

Again, the problem is that precision is explicitly asserted in instance document elsewhere (as in Databases), whereas here it is not.

If you want examples of interop issues with fractional seconds, you only have to look at Microsoft Office & SQL Server

http://support.microsoft.com/kb/225334

Note this problem was never fixed and described as “by design”. This affected our product which depended on these Microsoft components. Essentially a complete failure occurred in the MS component, since there was no code to deal with precision mismatches.

A SQL Server issue we also came up against

http://rightondevelopment.blogspot.com/2009/10/sql-server-native-client-...

And of course, the world-famous MySQL problem with not even supporting millisecond precision

http://stackoverflow.com/questions/2572209/why-doesnt-mysql-support-mill...

Note that this is due to the fact that SQL92 compliance does not dictate any precision beyond seconds.

Although I support the notion that we should allow flexibility to go beyond millisecond precision, I just want to explain that it does come at the cost of interoperability. Giving a strong steer that using millisecond precision is a good idea is what we should aim for. Perhaps in the future, we could add information to explicitly assert the precision of values into the spec in another attribute.

Min pointe er nok, at der ikke er noget åbenlyst rigtigt/forkert svar her. Det afhænger i høj grad af "intention" samt "øjnene, der ser".

:o)

Mark Gjøl

Jeg prøver ikke at være hverken på tværs eller klog, jeg forstår bare ikke helt pointen med at give lov til at bryde interoperabiliteten. De to formuleringer:
A. Best practice er 3 decimaler, men gør som du vil.
B. Gør som du vil.

Hvis man siger A, så vil nogen gemme med 3 decimaler, mens andre vil gemme i flere. For at sikre højst mulig interoperabilitet sørger man for at man kan læse så meget som muligt - eller holder sig stringent til standarden, og får problemer med dokumenter fra softwarepakke X.
Hvis man siger B, så tvinges alle til at supportere n decimaler, og alle kan læse alles dokumenter.

Hvad er fordelen i A?

Jesper Lund Stocholm

Hej Mark,

Hvad er fordelen i A?


Det bliver vel egentlig sagt meget godt i det jeg citerede med

Although I support the notion that we should allow flexibility to go beyond millisecond precision, I just want to explain that it does come at the cost of interoperability. Giving a strong steer that using millisecond precision is a good idea is what we should aim for.

(min fremhævning)

Hvis man ikke skrev noget, så var der absolut ingen hjælp af hente i standarden for, hvad et rimeligt mindste mål er. Alternativet for implementørene er jo at brute-force alle andre applikationer for at se, om de overhovedet understøtter faktioner i det hele taget - og i hvilken grad. Hvis man sagde, at "du skal bruge 9 decimaler", så ville implementører med højere krav komme i bekneb.

Vores udfordring er jo, som jeg sagde tidligere, at man gerne vil hjælpe implementører så meget som muligt - uden at lukke nogen ude. Det gør at man bevæger sig ind i et område, hvor man gerne vil "lede" eller "motivere" nogen i en bestemt retning - uden at kunne komme efter dem, hvis de ikke gør det.

Det er altid lidt svært, men jeg vil fastholde, at det er værre slet ikke at gøre noget.

Derfor er jeg fortaler for "should"-løsningen, for den signalerer "hensigt" - uden at forbyde alternativer ... samtidig med, at man ikke ændre mere end højst nødvendigt i standarden undervejs.

:o)

Peter Stricker

hvis jeg nu vil gemme "et halvt sekund", så skal det med din formulering persisteres som

0.500

.. hvilket er lidt mystisk, hvis du spørger mig.


... men mere præcist. Det er ikke sikkert, at den værdi der er repræsenteret ved 0.500 lige præcis er en halv. Det kan muligvis betyde et sted imellem 0.4995 og 0.5005 alt efter afrundingsregler. Men det betyder helt sikkert ikke 0.47.

Stod der derimod 0.5, så er det ikke sikkert, at den oprindelige værdi, inden den blev afrundet til en enkelt decimal lå mellem 0.4995 og 0.5005. Den kan have ligget mellem 0.45 og 0.55. Og derfor har du mistet en masse præcision ved ikke at forlange mindst tre betydende decimaler, som Jakob foreslog.

Eskild Nielsen

Jeg prøver ikke at være hverken på tværs eller klog, jeg forstår bare ikke helt pointen med at give lov til at bryde interoperabiliteten. De to formuleringer:
A. Best practice er 3 decimaler, men gør som du vil.
B. Gør som du vil.

Som jeg forstår det:

Du SKAL kunne udføre dine beregninger med millisekund præcision, og dermed kunne udveksle data svarende dertil med andre applikationer.

HVIS du modtager data med højere præcision, skal du som minimum kunne trunkere til din maksimale præcision.

Det må være trunkere, for en applikation der ikke har understøttelse for flere decimaler, kan vel intet fornuftigt gøre med de overtallige decimaler?

Så denne både og formulering kommer til at betyde at .500 er repræsentationen for en størrelse i intervallet 0.4995 - 0.5009 og ikke 0.4995 - 0.5005

Jesper Lund Stocholm
Peter Stricker

Dit eksempel er i øvrigt endnu et godt eksempel på, at det er nødvendigt at lade implementører vælge, hvor meget præcision de har behov for.


Så har jeg ikke formuleret mig tydeligt nok. Min intention var, at argumentere for at Jacobs[*] formulering

fractional seconds shall be expressed with three or more decimal places.


nok var den, du bør arbejde på at få indarbejdet i standarden. Den virker meget mere fornuftig end den formulering, du rettelig undrer dig over.

[*] Jeg vil gerne undskylde stavefejlen i mit tidligere indlæg. Det var simpelthen for sjusket.

Henrik Sørensen

Kære Jesper med flere.

Som jeg ser det er I netop på vej ned af en glidebane hvor I i bedste mening er på vej til at ødelægge standarden fordi I prøver at definere noget til et niveau der rækker ud over hvad I bør bestemme, da det dermed sætter en absolut grænse for hvad regneark under den nævnte standard vil kunne anvendes til - og dermed tvinger I leverandørerne til at opfinde/vedligeholde deres egen standard så de kan tilfredsstille deres kunders behov som med sikkerhed rækker ud over det som I har gang i.

I stedet for at definere hvor mange pladser der skal være efter kommaet og dermed begrænse standarden så tænker jeg at den rette vej er at definere hvilken TYPE af information I ønsker at anvende.

Hvis der er tale om at I alene vil udtrykke fraktioner af sekunder og disse altid er mindre end 1 så er INTEGER det rigtige svar.

Ønsker I at kunne udtrykke både rationelle og irationelle tal så er den korrekte type som normalt kan databehandles en REAL.

Det vil derfor være hensigtmæssigt at I definerer TYPEN og så blander jer udenom resten.

Så snart I begynder at diskutere hvor mange decimaler der skal være så begrænser I anvendelsen af de dokumenter, der kan laves med standarden da der med sikkerhed vil være rimelige behov som ligger ud over hvad I lige kan forestille jer.

Typen - i det aktuelle tilfælde REAL eller INTEGER - må antages at være generisk i standarden og gå igen mange andre steder. Derfor vil det være rigtigst at henvise til en for standarden 'global' definition, hvor man beskriver hvordan en REAL eller INTEGER noteres og evt. henviser til andre standarder under ISO eller lign. så man ikke risikerer at afvige fra noget der i forvejen er veldefineret.

Det undrer mig i øvrigt, at I overhovedet tænker at I skal opfinde et format for notation af TID. Hvorfor læner I jer ikke op af kendte tidsformater/notationer nu det handler om tid (sekunder), for der er med sikkerhed andre som har været dette igennem før jer og på et mere videnskabeligt niveau har diskuteret sig frem til de forskellige muligheder og deres rationaler og begrænsninger.

Jeg tænker at I også bør huske på at rigtig mange regneark benyttes til at importere/eksportere indhold til og fra databaser og at I derfor med fordel kunne kigge i retning af standardiseringsarbejdet på dette felt.

Udgangspunktet for dokumentformaterne er interoperabilitet og det er derfor vigtigt konstant at være opmærksom på ikke at opfinde noget der unødigt begrænser brugen af formatet.

Held og lykke med den fortsatte standardisering

/Henrik

Jesper Lund Stocholm

Jesper Lund Stocholm

Så er intentionen idiotisk.


Og for lige at kvalificere diskussionen lidt, så er en intention om at give noget guidance til foreslået opførsel (uden at kræve den) for at opnå bedre interoperabilitet jo bestemt ikke noget, som OOXML har fundet på. Jeg sad tidligere i dag og kiggede på RFC for HTTP response codes, og heri optræder ordene "SHOULD" og "MAY" hhv 50 og 21 gange. Hvis man kigger på HTML4.01 spec, så optræder ordene "SHOULD" og "MAY" hhv. 366 og 621 gange.

Generelt er intentionen, at man ønsker et veldefineret basis-regelsæt med veldefinerede og velbeskrevne begrænsninger - men tillader stadig afgivelser dog med specifikke ønskede (men ikke krævede) opførsler.

Vores mailkorrespondance er iøvrigt nu blevet offentlig på http://mailman.vse.cz/pipermail/sc34wg4/2012-March/002603.html og den indsendte DR til OOXML kan nu læses på https://skydrive.live.com/view.aspx/Public%20Documents/2012/DR-12-0004.d...

Log ind eller opret en konto for at skrive kommentarer

IT Businesses