Microsoft hopper på vektor-vognen

Så venter vi spændt på at se, om det er for at udvikle eller sabotere standarden.

SVG er en fed teknologi så jeg glæder mig til at det endelig ser ud til at få mainstream support.

...wait for us.

SVG er en fed teknologi så jeg glæder mig til at det endelig ser ud til at få mainstream support.

Vektorgrafik er en fed teknologi, SVG er et bloated halvfærdigt format som vel bedst kan betegnes som laveste fællesnævner. Det man kunne spare i filstørrelse ift. en PNG fil bliver ofte ædt op af XMLen. Ja, det kan bruges i praksis, men sådan rent teknologisk set er det sq ikke kønt.

Hvis man kigger på de nuværende 'hip' teknologier hos Microsoft, så er WPF og XAML (Silverlight) meget populært.

Og netop XAML benytter vektor grafik, så det er positivt hvis Microsoft kan bringe nogle erfaringer fra WPF over til SVG.

Og med SVG og HTML5, kunne IE jo gå hen og blive en helt brugbar browser :-o

Det er noget vrøvl at brokke sig over xml-markup overhead, for hvis man gerne vil have mindre filer og spare noget båndbredde kan man nemt komprimere dem, hvis browseren understøtter det og det gør alle moderne browsere.

Se: http://en.wikipedia.org/wiki/HTTP_compression

MS bruger primært EMF (Enhanced Metafile). EMF virker i IE men ikke mange andre browserer, ej heller Firefox.

Fantastisk at MS også kan finde ud af at bruge en åben standard i stedet for deres eget proportære format.

Det ender jo med at interoperabilitet bliver hverdagskost. Arh ok, måske for optimistisk :-)

Og med SVG og HTML5, kunne IE jo gå hen og blive en helt brugbar browser :-o

Jep. Håber virkelig, de bruger det som springbræt til at implementere ting som canvas, websockets og video i IE så hurtigt som muligt. Uagtet at disse ting ikke er opfundet i Redmond. Tiden må være til at droppe dumme æresbegreber og komme i gang. Det bliver i sidste ende en fordel for ALLE (om end jeg godt kan begynde at forestille mig HTML5-løsninger, som vil være i direkte konkurrence med mere lukkede MS-teknologier).

Så venter vi spændt..

Ja, den første version af SVG kom i 2001, så MS kunne jo som udgangspunkt vise deres gode vilje ved at understøtte en eksisterende SVG standard - det har der i hvert fald været rigeligt med tid til.

Men istedet kommer de og vil "forbedre" på SVG (jeg bruger anførselstegn pga. den hidtidige omgang med standarder man har set fra MS).

Skepsis er efter min mening helt berettiget.

Nemlig:

"Lead, follow, or get out of the way."

• Carsten

Det er noget vrøvl at brokke sig over xml-markup overhead, for hvis man gerne vil have mindre filer og spare noget båndbredde kan man nemt komprimere dem, hvis browseren understøtter det og det gør alle moderne browsere.

Du kommer ikke i nærheden af en størrelse som tilsvarer den faktiske datamængde. Med numeriske data i XML starter du typisk med en fil som er mindst 10 gange så stor som en tilsvarende kompakt ikke-komprimeret binær fil. Du kan så komprimere XML filen til noget meget mindre, som stadigvæk er en faktor 2 til 5 mere end en binær fil, men tager ufatteligt meget længere tid at indlæse. Millisekunder i stedet for microsekunder. Hvis du nogensinde synes at din computer er for langsom, så skal du vide at XML og andre lignende tåbeligheder er en stor del af forklaringen. Spild med fuldt overlæg foretaget i den overbevisning at det ikke gør nogen praktisk forskel.

Mig bekendt havde den version af Visio, som kom til Office 2003, SVG support!

@Jacob Christian Munch-Andersen

At SVG skulle være 'bloated halvfærdigt format som vel bedst kan betegnes som laveste fællesnævner', kommer vist mest an på om man anerkender XML som et fornuftigt format. Såfremt båndbredde skulle være et uløseligt problem, hvad ville du bruge som alternativ til SVG?

Sammenligningen med PNG er i øvrigt irrelevant da PNG er et bitmap baseret format.

Til brug på nettet vil PNG og SVG filer ofte være direkte konkurrenter.

Jeg sammenligner ikke med noget specifikt format, jeg kender ikke til indmaden af andre andre vektorgrafikformater end SVG. Jeg konstaterer blot at der er et misforhold mellem den reelle datamængde og filstørrelsen.

Der er fornuft i XML, så langt som til at det er lettere for mennesker at læse og skrive end binære formater. Om XML bliver anvendt fornuftigt vil jeg primært bedømme på 3 kriterier. Om der er brug for at mennesker læser og skriver formatet? Om den potentielle menneskevenlighed rent faktisk er opnået? Og hvor tungt den ekstra filstørrelse typisk vil vægte.

Hvem her piller selv ved indholdet af deres SVG filer? Og når I ikke gør det, er det så fordi at I bedre kan lige at bruge en grafisk editor? Eller fordi det er kropumuligt at hitte ud af? Med potentiale for at lave ganske komplicere billeder med vektorgrafik og bruge dem på nettet så vil jeg også mene at hvis SVG skal udfylde den rolle som det er tænkt til, så kommer filstørrelsen til at veje rimeligt tungt. Alt i alt er XML et rigtigt dårligt valg til SVG.

Grunden til at jeg er så mavesur er jo nok først og fremmest at der ikke er nogen alternativer til en åben udbredt vektorgrafikstandard, når W3C først har anbefalet et format så kan man ikke sådan lige få noget andet indført blot fordi det er langt bedre.

Der er fornuft i XML, så langt som til at det er lettere for mennesker at læse og skrive end binære formater.

Der er noget du helt har misforstået om XML der...

Fidusen ved XML er ikke at det er "human readable", (Hvilket jeg vil argumentere sjældent er tilfældet), men at du ikke skal skrive en ny parser til hvert nyt filformat.

For en applikation der allerede har en XML parser, betyder det a SVG er meget nemt at gå til: Man kan koncentrere sig om indholdet.

Så vidt jeg ved er der også en XML baseret bitmap standard i støbeskeen, tænkt som afløser for TIFF.

Poul-Henning

W3C er opmærksom på problemerne omkring datastørrelserne i XML. En standard for binær XML er under udvikling: EXI

Gevinsterne ved et standard metadata sprog som XML, f.eks parsing som PHK nævner, er bibeholdt i EXI.

Det betyder absolut intet at den rå xml fil er 5 gange større end det tilsvarende data som hårdt pakket binært data, komprimering tager sig jo nemt af det problem, tilgengæld er det meget svært at lave et binært format som er lige så fleksibelt og fremtidssikret.

Det interessante ved SVG er at det er en standard som gør det muligt at bruge flere forskellige værktøjer, incl. Javascript til runtime manipulering af DOM'en i stil med html.

Se på moderne formater som ODF, der er dokumentet blot en zip fil der indeholder xml filer, sidst jeg kiggede efter fyldte samme content i ODF mindre end samme content i legacy formater som .doc.

Jeg konstaterer blot at der er et misforhold mellem den reelle datamængde og filstørrelsen.

Husk på at der er tale om skalerbar vektorgrafik.
Hvad fylder et knivskarpt billede på 4kvm?

Helt enig!

Man får ikke alene en parser "foræret", men også en masse andre værktøjer - eksempelvis XSLT. At kunne transformere XML input til SVG direkte i browseren lyder rigtig interessant.

Jeg mener at have set et eksempel hvor beskrivelsen af et molekyle forelå i XML og så blev en SVG model genereret på baggrund af den. Efter min mening noget mere tilgængeligt end en bunke PNG'er på en server :)

Jeg synes XSLT er lidt for besværligt, men jeg kan rigtigt godt lide ideen i XML Schema og specielt i RelaxNG. Ideen med at du kan typechecke dine dokumenter gør at du kan behandle dem langt mere effektivt end hvis du ikke havde den mulighed.

Kva at det fyldere mere, og er dyrere at parse, så er det mindre problemer som ikke bør gøre formatet overflødigt. Man kan altid starte med et XML-format og så skrive det om til et binært senere, skulle man få brug for den øgede hastighed. En nogenlunde fornuftig softwarestak ville abstrahere inddata fra selve databehandlingen alligevel, så det burde ikke have nogen indvirkning på kildekoden heller. Båndbredde er forholdsvist billigt i forhold til mange andre ting, specielt under komprimering af dokumentet.

Der er noget du _helt_ har misforstået om XML der... Fidusen ved XML er ikke at det er "human readable"

Jeg vil nu påstå at det er en ret afgørende faktor for mange XML formater, af de store, åbenlyst XHTML, og RSS har nok også noget glæde af det. Dertil kommer et utal af applikationsspecifikke formater som er mere eller mindre selvdokumenterende, hvilket hjælper på udviklingen af tilføjelser m.m.

At du ikke skal skrive en ny parser til hvert nyt filformat.

Du skal stadigvæk oversætte fra parserens outputsprog til den data som bruges internt i programmet, det trin kan du springe over hvis du skriver en parser selv. Jo, det er da nok generelt lidt lettere at oversætte fra en parsers output, men det plejer nu ikke at være vanvittig svært at parse en velkonstrueret binær fil, når blot man har ordentlig dokumentation.

Så vidt jeg ved er der også en XML baseret bitmap standard i støbeskeen, tænkt som afløser for TIFF.

<pixel x="23" y="312">#ffffff</pixel> eller hvad?

W3C er opmærksom på problemerne omkring datastørrelserne i XML. En standard for binær XML er under udvikling: EXI Gevinsterne ved et standard metadata sprog som XML, f.eks parsing som PHK nævner, er bibeholdt i EXI.

Det hjælper bare ikke på SVG, med mindre selvfølgelig W3C bryder kompatibiliteten og udvider standarden til også at omfatte en EXI version.

Se på moderne formater som ODF, der er dokumentet blot en zip fil der indeholder xml filer, sidst jeg kiggede efter fyldte samme content i ODF mindre end samme content i legacy formater som .doc.

Legacy doc sviner også med pladsen. Et lille eksempel med Calc, Open Office 3.1, jeg skrive et "a" i a1, filen fylder 6695 bytes, jeg tilføjer så et "b" i b1, nu fylder filen 6819 bytes (+124 bytes), jeg ændrer b1 til "bc", så er vi oppe på 6873 bytes (+54 bytes). Udpakket er størrelserne 21070, 21276 (+206) og 21495 (+219).

Lektien: Zipning er damage control, ikke en magisk mekanisme som fjerner alt overhead.

Jacob,

Det virker som om fordelene ved XML er gået lidt hen over hovedet på dig.

Der findes biblioteker til stor set alle programmeringssprog, som kan håndterer XML. Men, hvis du begynder at parse output fra parseren, så er du jo lige vidt.

Det hvor XML er rigtig stærkt, er når du benytter de faciliteter som strukturen i XML afleder:
1) Sikring af konsistente data via XSD
2) Udtræk af indhold via f.eks. XPath og XQuery
3) Transformering via XLST
4) Etc.

XPath og XQuery, eller hvad dit bibliotek nu stiller til rådighed, gør det i vid udstrækning overflødigt at interessere sig for parserens interne håndtering, eller output format om du vil. I steder kan du fokuserer på indholdet, som jo er det egentlig interessante.

Derudover har XML, mere end noget andet format, gjort interoperabilitet til en leg. Hvis man vil have interoperabilitet ift. data mellem to eller flere stykker software, så er det muligt uden de store anstrengelser med XML.

I nutidens IT landskab, er manglende interoperabilitet ikke forsaget af knaphed på ressource og nedprioritering. Årsagerne er derimod historiske og/eller politiske karakter. Omstændigheder som ingen teknologi kan gøre noget ved.

Jeg husker tiden før XML.
1) Der skulle skrives meget kode for at hente, gemme og fortolke/parse data.
2) Alt software havde deres egen struktur på data. Strukturer der som oftest var direkte inkompatible.

I dag er det indholdet der skaber problemerne. Det er ikke datarepresentation på bit niveau.

Mvh
Carsten Sonne Larsen

Jacob,

Det virker som om fordelene ved XML er gået lidt hen over hovedet på dig.

Der findes biblioteker til stor set alle programmeringssprog, som kan håndterer XML. Men, hvis du begynder at parse output fra parseren, så er du jo lige vidt.

Det hvor XML er rigtig stærkt, er når du benytter de faciliteter som strukturen i XML afleder:
1) Sikring af konsistente data via XSD
2) Udtræk af indhold via f.eks. XPath og XQuery
3) Transformering via XLST
4) Etc.

XPath og XQuery, eller hvad dit bibliotek nu stiller til rådighed, gør det i vid udstrækning overflødigt at interessere sig for parserens interne håndtering, eller output format om du vil. I steder kan du fokuserer på indholdet, som jo er det egentlig interessante.

Derudover har XML, mere end noget andet format, gjort interoperabilitet til en leg. Hvis man vil have interoperabilitet ift. data mellem to eller flere stykker software, så er det muligt uden de store anstrengelser med XML.

I nutidens IT landskab, er manglende interoperabilitet ikke forsaget af knaphed på ressource og nedprioritering. Årsagerne er derimod historiske og/eller politiske karakter. Omstændigheder som ingen teknologi kan gøre noget ved.

Jeg husker tiden før XML.
1) Der skulle skrives meget kode for at hente, gemme og fortolke/parse data.
2) Alt software havde deres egen struktur på data. Strukturer der som oftest var direkte inkompatible.

I dag er det indholdet der skaber problemerne. Det er ikke datarepresentation på bit niveau.

Mvh
Carsten Sonne Larsen

Det betyder dog ikke, at den næste version 9 af Microsofts browser vil understøtte SVG, forlyder det fra et andet medlem af arbejdsgruppen.

Så det Dengler siger er altså bare tomme ord uden reelt indhold?

Det virker som om fordelene ved XML er gået lidt hen over hovedet på dig.

Overhovedet ikke, jeg missede blot heller ikke ulemperne, og jeg sorterede salgsgassen fra, så var der ikke så meget tilbage at være begejstret for. Siden da har XML haft en fordel ved at være de facto standard, det har givet en del værktøjer som gør XML mere brugbart.

Derudover har XML, mere end noget andet format, gjort interoperabilitet til en leg. Hvis man vil have interoperabilitet ift. data mellem to eller flere stykker software, så er det muligt uden de store anstrengelser med XML.

Du mener fx mellem MS Office og Open Office, det problem er jo praktisk talt forsvundet siden OOXML :-/

Ja, når begge programmer bruger det samme XML format og ellers er enige om alle detaljerne så giver et XML format kompatibilitet, ligesom et binært format under samme forudsætninger.

Fremgangen i interoperabilitet er vist mere et resultat af at vi har fået universelle standardformater for en del ting end at der er brugt XML.