I spent last week in Redmond talking to Microsoft about M and Oslo. The question at the back of my mind before I went was "Does M really have the potential in the long term to be an interesting and useful alternative to XML?". My tentative answer is yes. Here's why:
- Although M, as it is today, is interesting in a number of ways, it is obviously a long way from being a serious alternative to XML (at least for the kinds of application I am interested in). One of my concerns was that I would hear "It's too late to change that". I never did: I was pleasantly surprised that Microsoft are still willing to make fundamental changes to M.
- 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.
- Microsoft is addressing the whole stack. An alternative to XML needs to provide not only an alternative to XML itself but also alternatives to XSD/RELAX NG and XQuery/XSLT.
- Microsoft seem to be designing things in a principled way; they are paying attention to the relevant CS theory. For example, ML seems to be a major influence. They are making an effort to produce something clean, elegant, even beautiful, rather than doing just enough to get a product out.
- Microsoft seem willing to take documents seriously. This is a make or break issue for me, because the kind of data I care about most is documents and M, as it is today, is not useful for documents. This was probably the issue we spent the most time on; I talked a lot about the importance of mixed content. One of the Microsoft team suggested the goal of using M to do the M specification. I think this sort of dogfooding will be very helpful in ensuring M works well for documents.
Of course, it's early days yet, and it's hard to tell how much leverage M will get, but there's enough potential to make me want to be involved.
Have they addressed how they will license relevant patents? IIRC, that is the issue against Mono right now, and that also will be the issue against M if not addressed clearly and early.
Meh; as soon as I try to get on their site and view some presentation/video, I have to download Silverlight. Doesn't seem like openness/willing to participate to me.
They have addressed the patent issue by undertaking that the finished M specification will be covered by their "Open Specification Promise".
You can download the videos without installing silverlight by clicking on the "Download Video" link to the right.
"M really ha[s] the potential in the long term to be an interesting and useful alternative to XML"
Why do we need one - what are the limitations of the XML family of standards that you hope M will address?
> documents is a make or break issue
what kind of documents? XML? Or, documents like specs or whatever, you can parse them for whatever reason?
I'm looking at M et. al. to handle DSL-based documents such as specifications:
> what are the limitations of the XML family of standards that you hope M will address?
readability. there's a lot of markup in it that's not needed to get the point across w/ many XML documents. They're crowded with meta/markup.
DSLs have long been used to convey human-readable information w/o all the meta/markup. And, to present a schema or format that makes sense to the specific problem space (aka "domain" in "domain-specific languages) that XML doesn't handle well at all.
hmmm. No reply. Dead post, James?
As for XML replacements, there were DSLs all over the place before XML was ever around. Most of the shops I know using them are still shaking their head, 'why was XML chosen, with all its markup and poor human readability? A DSL(s) could have been done just as well." Once it was mainstream, myself and others billed hours and hours digging it out of comms protocols, it jammed so many systems it was ridiculous. We added a new field to all of the DSLs in our suite, ACRONYM, for one reason: XML, keep the tags/labels short. XML should have never been used in many places it was, and DSLs were being used for cross systems talk very nicely.
Many say XML caught on for one reason: marketing. "Some new, great technology" that's led us backwards in some respects while the alternatives were there to do all XML could (as much as I can think of) + avoid the headaches XML has.
I think they might be receptive to the idea of open sourcing the SDK components of Oslo/M and keeping the higher level tools proprietary.
If enough of us make a point that this is worth doing, we could change their minds.
"M being an alternative to xml due to readability?".
If that's the concern, then why not have a tool that simply grabs any xml and makes it more readable?
Anyways, DSLs were around a long time. and you can express them in xml if you like. Anyway the whole point of this fruitless exercise is lost on me.
Post a Comment