looking at the current bits i can see a transform from M to XML.
But what seems to be missing is a transform from (XSD+XML) => M Schema + M
Any plans for this?
I think you need to support this scenario as most metadata (or models as you call them)
is now encoded as XML
But what seems to be missing is a transform from (XSD+XML) => M Schema + M
Any plans for this?
I think you need to support this scenario as most metadata (or models as you call them)
is now encoded as XML
I like to think of M interop with other data formats in two very interesting and different scenarios.
One is exactly what Tim asked about - how do we take M data (which we call MGraph) and interoperate with other data formats, such as XML? Truthfully the mapping is pretty straight forward and we've prototyped it enough and have an initial implementation. It needs improved engineering before we declare ship ready, but there you have it.
We also think about interop at the schema level. For example, if we transform an MGraph to XML, then wouldn't it be great to transform the representative schema for that data into XSD? That's something we haven't quite done yet, but again I don't think that it would be hard, just work. We don't really have that booked to implement right now. Do people see a huge need?
Also, there's interop at the grammar level. This is probably not something we talk about much because there you really need to consider functional mapping. In other words, a grammar is just a function from character* to structured data (MGraph). Mapping that from one language like M to another like XSLT is quite a complicated problem and not likely something we'll tackle outside of research interests.
Now, there's another really big set of scenarios, quite orthogonal to the external interop ones above. I call these internal interop, or how to enable embedded DSLs or user-defined data structure and types within M. Sounds quite mystical and abstract :)
Now, there's another really big set of scenarios, quite orthogonal to the external interop ones above. I call these internal interop, or how to enable embedded DSLs or user-defined data structure and types within M. Sounds quite mystical and abstract :)
It means a couple of things. First, what if you wanted to write your own syntax for values inside of an M program. For example, suppose we didn't have a GUID type nor a textual representation for GUID values. Wouldn't it be great if you could tell M - "hey this is my syntax for my data"? We're thinking about that scenario, but nothing is committed to implementation yet.
Second, what if you could write your own DSL inside of M that would produce the equivalent of M program constructs, such as types and functions. This is what we call 'meta-programming'. We have lots of dreams to do this, and we're working towards that, but it's most likely a V2 priority not a V1 priority.
As always - I'd love your feedback on this.
Posts
12 comments:
1) Haven't found M->XML, neither searched for it. Do you have some link? Or hint?
A functional Mapping from and to XSD and M shouldn't be a big deal. The only thing to handle here, is the difference between attributes and elements, as well as the notion of namespaces, right?
Xsl is a piece of technologie that just isn't covered in M, so this should be hard.
Xpath could quite easily map to Linq2M.
2) About Metaprogramming:
I think the issue here is to support mixed grammars in M at all! But then you have to change your parsing algorithm, don't you? If you have that, it would be nice to implement it for Mgraph too. Only supporting it in M, but not in custom grammars would make me angry :-)
3) BTW, in the current bits, is it possible to directly validate a DSL AST against a schema?
4) Have you ever thought about XML literals in M?
I would find a mapping to both Xml and Xsd extremely useful, almost a requirement for my development team to get on board with adopting M anytime soon. Right now we have a huge investment in our version of 'model definitions' that we built by starting with xml schemas, using the xsd.exe tool to produce classes that parse xml, and using the VS xml editor (with intellisense due to the schemas) to author instances of our models. We store our xml documents (model instances) in our application SQL Server database which then becomes the authoritative store for our metadata.
So the concept of models, schema, a repository, and tooling support to enable declarative programming is well understood by my group (a mid-size ISV with ~100 .Net developers ranging in experience with complex business apps from 0 to 15 years ) and I completely get the eventual payoff painted by the Oslo vision.
But right now we have dozens of models defined in terms of fairly complex xsds in terms of number of elements and attributes, and we have literally thousands of instance documents defined in xml. Our application has hand rolled versions of many of the concepts of Oslo/M but I would love for us to one day transition to the .Net platform version of these concepts to get us out of that part of the glue and also take advantage of the added benefits of M that we don't have anything for (such as custom DSLs beyond our xml schemas).
But right now I can imagine my pitch on the state of M:
My boss: What does M do?
Me: 3 things;
It lets us do models like we do today with xsd.
It lets us build parsers like the ones we get for free from the xsd.exe tool today that maps docs to classes for use with the XmlSerializer.
It gives us a language like xml to create instances of our models like we do today using xml.
My boss:
So M lets us accomplish everything we do today using the ubiquitous standards of xsd and xml, but it uses a completely new language that is not yet as.. biquitous... Not sure I get the payoff there - but how hard is it to convert our stuff? I assume they have a tool to help us leverage our investments in xsd?
Me: As of today nothing in M/Oslo will help with that.
My boss: Nevermind then. Call me when the M toolset/adoption catches up with our current toolset.
XML is dead. Long live 'M'...
Hm. Asking for feedback, and then not answering to feedback is not nice :-)
@lars - I'm such a bad guy. It's on my to do list :)
The 'M promise' is to establish a toolchain and modeling environment that supercedes what exists today. To prove the theory, demonstrating that 'M' can support existing languages (e.g. C#, Java, XML) and models (e.g. UML, XSD) is important. Not to mention the migration and interoperability challenges mentioned in the blog comments here. If my team is building a system in 'M', and they obtain an XML or XML Schema definition from a third party, how do they integrate the external 'model' into the system? Lack of XSD/XML interoperability limits the value of MUrl and M.
Have you read:
http://codebetter.com/blogs/jeremy.miller/archive/2009/09/09/sorry-but-i-just-don-t-get-oslo.aspx
That's a great post with some very actionable feedback.
PDC will be telling. Merging a textual language with a data access stack is a reasonable chess move. It's not checkmate.
The biggest change to come will be that M, the language, is getting a substantial facelift from the current 0.5 version focused on data modeling, to a 0.9 version that is addresses some of the behavior issues that people have correctly raised.
I'm excited with the spec direction. We're working very hard on it, and hope to have a preview at PDC 09.
This post of yours speaks of the very same kind of topics of my still ongoing "obsessions", though I sadly haven't much material time to dedicate to.. well, tame. I'm progressing, slowly, but progressing; I at least tried to phrase down a rationale there ...
http://www.ysharp.net/the.language/rationale/
...before more concrete syntax, ontology, & "reference implementation" (or as a matter of) all three coming soon.. I hope.
Regards,
Cyril
Wow - I'm really interested to see more of Y#
http://stackoverflow.com/questions/2847607/how-can-i-create-xsd-files-from-m-documents/2928114#2928114
You actually make it seem so easy with your presentation but I find this matter to be really something that I think I would never understand. It seems too complex and extremely broad for me. I'm looking forward for your next post, I will try to get the hang of it!
Post a Comment