Farvel og tak til XML

Det er nok lidt tidligt at dømme XML ude, selv om Microsoft satser på M. F.eks. vil bl.a. OOXML ikke uden videre kunne laves om til at bruge M i stedet for XML.

Men personligt vil jeg ikke savne XML. Om M er bedre kan jeg dog ikke sige uden at have set en bedre oversigt end den fra linket.

OOXML? Det kommer vel i så fald til at hedde Open M, fordi det er nemmere at skrive ...

En anden pudsig ting er, at James Clark taler om ..

[...]M needs to end up as a genuinely open standard.

Det er altså ikke nok med en "open standard". It has to be GENUINE! ;)

Sprogspecifikationen kan hentes her:

http://msdn.microsoft.com/en-us/oslo/dd548667.aspx

Det ser ud til at være kraftigt inspireret af ML.

Om det er godt eller skidt, ved jeg ikke, umiddelbart virker det mærkeligt at det ligner et programmeringssprog med paranteser, { }.

Er der nogen der kan give et 5 liniers crashcourse i M, og M's velsignelser.?

Og er M beregnet til at skulle agere programmeringssprog, eller er det beregnet for at være databærende?

Endelig, er der behov for endnu et format/sprog?

/Christian

Ja, det er super (måske). Det ser ud til at man ønsker sig at M nemt kan oversættes til SQL og har derfor samme semantik. Objektorienterede konstruktioner ser det ikke ud til at der er lagt vægt på.

Dette eksempel viser definition og populering af en datatype:
[code=csharp]
type Person {
Id : Integer32 = AutoNumber();
Name : Text;
Age : Integer32;
Spouse : Person;
} where identity Id;

People : (Person where value.Spouse in People)*;
[/code]
The Spouse field references another Person. One way to initialize this structure is to explicitly assign the identity of each instance:
[code=csharp]
People {
{ Id = 0, Name = "Jack", Age = 23, Spouse = 1 },
{ Id = 1, Name = "Jill", Age = 25, Spouse = 0 },
}
[/code]

M er et sprog til at skrive textuelle DSL'er.
M består af 3 elementer, Mscheme, Mgrammer og Mgraph ... som forenklet kan sammenlignes med hhv xsd, xslt og xml.

Et eksempel kunne være dette DSL fra samples i SDK'et:

[code=bnf]

Music
- - - D
C C# F G
E E - D
A E - E
G F - E
D C D E
A E D D
D E A C
[/code]

...med den tilhørende grammar:

[code=bnf]
//------------------------------------------------------------
// Copyright (c) Microsoft Corporation. All rights reserved.
//------------------------------------------------------------

/*
The Song language allows a songwriter to compose a song
that starts with "Music" and is followed by zero or more "-"
characters or characters for the range of notes "Ab" to "G#",
delimited by the "," character.

Additionally, whitespace characters can now be included in  
input and will be ignored during processing unless the  
RestOrNote token rule is being matched.

Finally, a song is defined as having zero or more bars where each bar  
contains a combination of four rests and notes.  

*/
module SongSample
{
// Make the Common language (and its rules) visible to languages
// in other modules that share the SongSample namespace
export Common;

language Common  
{  
    // Parameterized List rule          
    syntax List(element)   
        = n:element => [n]   
        | n:element l:List(element) => [n, valuesof(l)];  

    syntax List(element, separator)   
        = n:element => [n]   
        | n:element separator l:List(element, separator) => [n, valuesof(l)];  

    // Whitespace  
    syntax LF = "\u000A";  
    syntax CR = "\u000D";  
    syntax Space = "\u0020";  
    syntax Whitespace = LF | CR | Space;  
}  

language NotSoCommon {}  

}

module Languages
{
/*
Only make the Common language (and its rules) from the MSGrammar
module visible to languages in this module scope. Specify an alias
for the Common language that rules in languages in this module use
to reference the rules in the Common language with.
*/
import SongSample { Common as C };

language Song  
{           
    // Notes  
    token Rest = "-";  
    token Note = "A".."G";  
    token Sharp = "#";  
    token Flat = "b";

    token RestOrNote = Rest | Note (Sharp | Flat)?;  

    // Keywords  
    syntax Music = "Music";  

    // A song can have zero or more bars, where each bar  
    // contains a combination of four rests and notes.  
    syntax Bar = RestOrNote RestOrNote RestOrNote RestOrNote;  
    syntax Bars = b:C.List(Bar) => Bars[valuesof(b)];  

    // Initial rule  
    syntax Main = m:Music b:Bars => Song[b];  

    // Ignore whitespace  
    interleave Whitespace = C.LF | C.CR | C.Space;  
}  

language AnotherLanguageThatNeedsLists  
{  
    // Reference List rule in Common language  
    syntax ListOfAs = C.List("A");  
}  

}
[/code]

...og den resulterende graph til fortolkning:

[code=csharp]
Song[
Bars[
Bar[
"-",
"-",
"-",
"D"
],
Bar[
"C",
"C#",
"F",
"G"
],
Bar[
"E",
"E",
"-",
"D"
],
Bar[
"A",
"E",
"-",
"E"
],
Bar[
"G",
"F",
"-",
"E"
],
Bar[
"D",
"C",
"D",
"E"
],
Bar[
"A",
"E",
"D",
"D"
],
Bar[
"D",
"E",
"A",
"C"
]
]
]

[/code]

Min kollega Henrik plejer at sammenligne det med Jax - lex compiler, andre med ML og DougP PM på M, mener at det har store lighedstræk med Smalltalk. Jeg ser det stadig som et mere fleksibelt XML. Jeg håber at blive klogere.

Tak, nu vil jeg nu nok sige at Lars's eksempel gav mest mening.

Men jeg har stadig lidt (mildt sagt) svært ved at forstå formålet med M.

XML er et fint og rimeligt nemt format (endda tilnærmelsesvis læsbart, og i hvert fald dechifrerbart) at benytte til dataudveksling.

Til programmering findes der rundt regnet en mullijard programmeringssprog, hvor det enkeltes proselytter mener at det er det eneste sagliggørende.

Så hvorfor i himlens navn opfinde (endnu) et nyt format der ovenikøbet begynder (eller nærmere går tilbage til) at rode programmering og data sammen?

/Christian

Og så et lille PS:
Det lader til at V2 formattering af programmerings snips først virker efter indlogning - i hvert fald gav Renes indlæg ingen mening før.

Men jeg har stadig lidt (mildt sagt) svært ved at forstå formålet med M

Jeg blev en smule klogere, men der skal forklaring af de enkelte elementer til, før jeg har den fulde forståelse.

XML er et fint og rimeligt nemt format (endda tilnærmelsesvis læsbart, og i hvert fald dechifrerbart) at benytte til dataudveksling.

Jeg synes, at XML er hverken nemt eller særligt læsbart.

Den del af M, der svarer til "rå" XML er sådanset bare ren tekst. Det er først, når man angiver en grammatik, at den gives en struktur. Det modsvarer, at man giver et schema til XML. Så dataformatet i M er på en måde simplere end XML, da der ikke er a priori krav til udseendet. Til gengæld bliver indlæsningen mere kompliceret, da man skal skrive en kontekstfri grammatik og generere en parser i stedet for at bruge en generisk XML parser. Til gengæld behøver man ikke at sende den indlæste tekst gennem en schemavalidator, da syntaksanalysen allerede har verificeret (det meste af) det, som et schema ville.

En anden fordel er menneskelæsbarhed: XML er mildt sagt stygt at læse (og skrive), men med de ekstra friheder, der er i dataformatet i M, kan man skrive noget, der er mere naturligt. Tag Renés musikeksempel. Det ville i XML se ud som noget i stil med den resulterende graf, dog med endtags men uden anførselstegn.

Det lader til at V2 formattering af programmerings snips først virker efter indlogning - i hvert fald gav Renes indlæg ingen mening før.

Jeg havde ingen problemer med at læse det, så problemet er noget andet. Da siden gentegnes efter login, er der nok noget, der var gået galt ved første tegning, men det havde nok kunne klares med en reload.

Hej Rene

Du har vel ikke tænkt over om MS-udviklerne måske er vilde med Oslo fordi de lider af et Stockholm Syndrom? ;-)

/Kim

Hej Rene,

Fængende overskrift - men kom igen ;-)

Selv MS gør vel ikke krav på at have lavet en afløser for XML? I MLanguageSpecification står der:

The "Oslo" Modeling Language ("M") is a language for modeling domains using text.

Modeling using text has some advantages and disadvantages over modeling using other media such as diagrams or clay. A goal of the M language is to exploit these advantages and mitigate the disadvantages.

M ser ud til at være særdeles velegnet til at modellere relationelle data og til at flytte relationelle data. Måske kan M være svaret på repræsentationen af tabulære data, som vi alle dage har været lidt irriterede over at skulle pakke ind i XML.

Sammenligner man XML Schema med M (sproget) ser det ud til at man skal være MEGET mere omhyggelig for ikke at risikere, at acceptere data som næppe er hensigten at acceptere. Vi er lidt tilbage til de gode gamle dage, hvor man skrev sin egen EBNF, men med et langt rigere sprog. Det er vel netop særdeles velegnet til at lave nye DSL'er, men ser ikke ud til at være en erstatning der hvor XML har sine styrker. (Her taler jeg ikke om udveksling af simple tabule data).

Mao. Jeg tror ikke at M er svaret på udveksling af mere komplekse strukturerede forretningsdokumenter (tinglysningsdokumenter, fakturaer, kataloger). En transformation kan naturligvis nedbryde denne type data i noget, som med fordel kan konsumeres med M.

Sammenligner man XML Schema med M (sproget) ser det ud til at man skal være MEGET mere omhyggelig for ikke at risikere, at acceptere data som næppe er hensigten at acceptere.

Der er vel ikke nogen der kunne finde på at skrive en service der alene validerer sit input vha. XML Schema???

Kim,

Der er vel ikke nogen der kunne finde på at skrive en service der alene validerer sit input vha. XML Schema???

Nej da - men man kan tilsyneladende komme længere med M end man kan i XML Schema, men det kræver at man er omhyggelig. Der er et HelloWorld eksempel i MLanguageSpecification som illustrerer hvor det kan gå galt.

Er jeg den eneste der med det samme synes at dette ligner Google Protocol Buffers? http://code.google.com/apis/protocolbuffers/docs/overview.html

Håber virkeligt ikke at dette bare er endnu et eksemple på Microsoft's "so ein ding muss wir auch haben", men vi skal selvfølgelig lave den selv. ???

Er jeg den eneste der med det samme synes at dette ligner Google Protocol Buffers? http://code.google.com/apis/protoco...

Ja det ligner, og opfylder nogle af de samme behov. Men M kan tilsyneladende oversættes til SQL udtryk, så på det område går M et langt skridt videre. Det er ikke en triviel øvelse, hvis jeg husker min databaseteori korrekt.

Håber virkeligt ikke at dette bare er endnu et eksemple på Microsoft's "so ein ding muss wir auch haben", men vi skal selvfølgelig lave den selv. ???

Som med så mange andre projekter, er det formodentligt blot en lille gruppe, der står bag M. Det kan være svært at være informeret om alle relevante projekter, hvis de ikke har vundet større udbredelse eller opmærksomhed. Det vil ikke være den første gang, at 2 hold af udviklere har været gennem den samme øvelse og med samme formål.

Hvor passer OWL ind i dette billede?

Jeg faldt lige offline en dags tid og skylder nogle kommentarer.

@ Martin,

Jeg ved stadig ikke hvad en "rigtig" standard er, men du har ret i at det er en udfordring.
Lige præcis den sætning som du henviser til:

Microsoft recognize that M's long-term potential would be severely limited if it was a proprietary, Microsoft-only technology. I believe they realize that M needs to end up as a genuinely open standard. They've already made initial steps towards a more open process for M. On the other hand, they don't believe in design by committee. (And having seen some of the abominations that design by committee can produce, I can certainly sympathise with that.) There's a senior Microsoft guy that gets to make the final call on all design decisions. In other words, it's a benevolent dictator model. I'm OK with this in principle (although I like it even better when I'm the benevolent dictator). I think it's worked really well in a number of cases (C# and Python spring to mind). But obviously it all depends on the qualities of the particular benevolent dictator. From my interactions so far, he seems like a really smart guy and he's willing to listen.

viser tydeligt, mange Microsoft folks syn på åbenhed. Dels at man gerne vil være åbne, men at man på den anden side ikke vil falde i uproduktivt komitearbejde.

Iøvrigt skægt at bemærke at James Clark tilsyneladende har det lidt på samme måde, selv om WG arbejde formentlig betaler en stor del af hans løn.

@ Christian,

Tak, nu vil jeg nu nok sige at Lars's eksempel gav mest mening.

Jeg postede et eksempel fordi jeg mente at Lars Be's eksempel ikke viser at M primært er et DSL til DSL'er og det mener jeg at Music-eksemplet viser.
Relationen til SQL bliver først rigtig vigtig når modellen (i M) skal persisteres f.eks i en database. Det er i min mening, men jeg har ikke kigget nok på M pt til at danne mig det fulde billede ... så med alt mulig forbehold fordi M ikke er færdig endnu.

Angående formateringen: Så var der 5 minutter hvor koden stod uden formatering fordi jeg jo ikke havde et code=M!!! Så jeg måtte vælge noget der lignede og du har nok set koden inden jeg fik formatteret.

Angående XML så er jeg enig med Torben i at det ikke nødvendigvis er verdens simpleste teknologi

-Syntax og wellformedness: XML
-Hjælpe specs: Xml Namespace, canonicalization, encryption og signature
-Type definitioner: DTD, Xml Schema Definition og XmlInfoSet eller Post Schema Validation Infoset (PSVI)
-Kovariante datatyper: Relax NG eller Schematron
-Funktionel Programmering: XSLT
-Forespørgelser: XPath og måske XQuery

Dertil kommer så de XML "DSL'er", som kan være en god ide at kende afhængig af arbejdsområde f.eks SOAP, WSDL, deployment og configurations filer i diverse platforme som .Net og Java ... osv eller de branche specifikke SWIFT, XBRL, EFakturaen, ...

Selv om jeg mener det er kompliceret, så dermed ikke sagt at der pt er et alternativ! Men jeg, en nysgerrig IT professionel (og ansat hos Microsoft), er nød til at kigge på M og andre alternativer.

@ Kim,

Suk! :-)
Jeg er sikker på at der på et tidspunkt kommer et kodenavn: Stockholm (og jeg tror ikke at vi behøver tage gidsler!!)

@ Mikkel,

Fængende overskrift - men kom igen ;-)

Jeg er bare den glade bringer af budskabet:

"Does M really have the potential in the long term to be an interesting and useful alternative to XML?". My tentative answer is yes

Okay, så der er et stykke fra "potential" til at erklære XML død, men hey, jeg kender mine virkemidler og jeg fik jo dig til at læse posten :-)

@ Mikkel og Lars Bj

Jeg tror at DSL aspektet af M er det, der gør de to (M og GPB) væsentlig forskellige. Som du er inde på, Mikkel, er M til DSL'er med alt hvad det indebærer.
Hvis I kigger på MGrammar delen så er det en så central del, som jeg ikke umiddelbart kan se i Goggle Protocol Buffers. Jeg opfatter mere GPB, som et xml alternativ og groft set en JSON ortogonal

@ Morten,

Hvis du mener Web ontology language, så er det for mig et DSL. Et DSL som f.eks kan skrives i M!
Jeg har ingen erfaringer med OWL udover at jeg har kigget og kigger på RDF som OWL enabler nu og da.