Slashdot Mirror

← Back to Stories (view on slashdot.org)

Microsoft Research's C-Omega

Posted by timothy on from the at-long-last dept.

Microsoft Research has produced a data-oriented programming language by merging C#, XPath and SQL. O'Reilly's XML.com website the inside scoop on the language in the article titled Introducing C-Omega written by Dare Obasanjo.

1 of 49 comments (clear)

  1. makes me cringe by Anonymous Coward · · Score: 2, Interesting

    I read this article when it came out. It made me sad to see this kind of stuff from a group with "Research" in the name (the of course you see the "Microsoft" and you realize this "research" is actually just Microsoft's "buzzword factory").

    Let's see the level of discourse here:

    unlike prior data interchange formats, XML can easily represent both rigidly structured tabular data (e.g., relational data or serialized objects) and semi-structured data (e.g., office documents).

    First of all, "relational data" is like saying "calculus numbers". I assume he means "relation value" when he says "relational data".

    Relation values are not tables. A table is a representation of a relation value. Relations represent sets. Both the attributes and the tuples are unordered for instance, it's hard to draw a picture of something that has no intrinsic order.

    The relational model is not "rigid", that's the whole point, you can use relational algebra to create arbitrary expressions, and if your constraints are correct, you can derive any correct fact from your database. This author clearly thinks the relational model is just a "bunch of tables" and rejects it without further thought. It would be more correct to say XML uses a rigid tree structure, while relational databases represent any possible data structure.

    Serialized objects are not tabular, they are ad-hoc depending on what library you are using. Some libraries use XML. Again he should know this.

    Basically it doesn't make sense to group "relational data" with "serialized objects" and call them both "tabular data".

    Next is the favorite buzzword of the XML practitioner: "semi-structured". I have no idea what that means. XML documents are streams of UTF-8 (or similar) characters. This is a rigid structure. At the next level of abstraction, they are a tree of nodes. Again, rigid structure. The structure of the tree can be further constrained by schema, but even if it isn't, it's still rigidly structured. How could you parse it, otherwise?

    So already we know this "research" is just going to be a misunderstanding of existing data models with some programmer-friendly buzzwords thrown in. As expected: if they truly understood data models, they wouldn't have written this paper or invented this language to begin with!

    The former tends to be strongly typed and is typically processed using object-XML mapping technologies, while the latter tends to be untyped and is usually processed using XML technologies like DOM, SAX, and XSLT.

    So tabular data is strongly typed and processed with object-XML technologies. Wouldn't it be processed with tabular-XML or tabular-object technology? I've used tabular data (like CSV) and I've never needed objects or XML with it.

    In the case of processing strongly typed XML using object-XML mapping technologies, there is the impedance mismatch between programming language objects and XML schema languages like DTDs or W3C XML Schema.

    Okay, now I get it.. we're processing strongly typed XML using object-XML mapping technologies. Based on the previous sentences, I think this means strongly-typed XML is actually equivalent to tabular data, right? I guess the author is just confused. I know I am.

    And there's another favorite buzzword: impedance mismatch. Usually this means the programming is trying to match up two different concepts without realizing it (like variables to types or values to variables). I think the author here just means "requires awkward syntax".

    This is the point where I usually stop reading a paper. But I glanced at the rest. Basically he 1) creates a hierachical, application-specific database. Both of these concepts were rejected decades ago. And 2) he shows a language which is basically the same as existing languages except you don't need to put your XML and SQL in double-quotes. Okay. This can be valuable. But he uses something that looks like SQL, rather than relational algebr