Sunday, December 23, 2007

Eclipse and the OMG: Two Great Things that Go Great Together

The Object Management Group is planning a workshop to coincide with EclipseCon. The call for submissions is out. More details are available in the announcement Kenn posted to the modeling newsgroup.

The OMG has a long history as a place for developing modeling-related specifications and Eclipse has become the place where the de facto reference implementations reside. So I wrote a little derivative poem to commemorate this grand convergence of specifications and their implementations.


Two roads converged in a yellow wood,
And sorry we had to travel both
And be two travelers, long we stood
And looked down each as far as we could
To where they met in the undergrowth.

Then we each took our path, as just as fair,
And having perhaps the better claim,
Because it seemed greener for want of wear;
Though as for that the passing there
Had worn them really about the same.

And both that morning equally lay
In leaves few steps had trodden black.
Oh, we kept the other for a different day!
Yet knowing that our way seemed the better way,
We doubted we should ever come back.

We shall be telling this with a sigh
Somewhere ages and ages hence:
Two roads converged in a wood, and we--
We each took the one less traveled by,
And that has brought us to a common point.

Friday, December 21, 2007

Can a Tiger Change its Stripes?

I recently set up a community tank with a diverse collection of plants and fish.


To manage the community well, you have to choose your fish carefully to ensure they will fit in with the rest of the community. This little tiger striped loach fits in rather well.


With the recent Tigerstripe proposal the modeling PMC was faced with a similar type of choice. The proposal was originally written as a general purpose model driven development technology that would help round out some of the gaps in the modeling project's technology. Eric Dillon gave Rich and I an overview and a demo of the technology. We immediately expressed concerns about a number of detailed issues.

We had to wonder, is Tigerstripe an industry vertical model driven development technology used to define Telcon standards or is it a general purpose model driven development technology based on existing standards? As I said, initially Tigerstripe was proposed as a general purpose model driven development technology but upon closer scrutiny, the proposal was changed to be an industry vertical model driven development technology, though obviously the actual technology itself didn't change, only the way it is presented. This still leaves doubt as to the true intended nature of this technology and how it integrates with the established Eclipse community.

If Tigerstripe is really intended as a technology for defining industry vertical standards it should be strongly grounded on existing standards, e.g., profiled UML would be one reasonable approach, yet the relationship to UML is somewhat in doubt. The proposal seems to characterize it as a subset of UML, but I'm not sure what to call the model, since Tigerstripe seems to be a brand that denotes many things. In fact, I'm not even sure if there is an Ecore/EMOF-based metamodel for it.

An alternative to profiled UML would be the definition and development of a domain specific language, but that does not appear to be the proposed approach. Defining an EMOF/Ecore model for a domain specific language would make the technology well integrated with the existing modeling project infrastructure and would make it much more clear the nature of the target domain.


We were also concerned about rebranding a commercial brand with Eclipse's stamp of approval. It seems to me that allowing a proposal to proceed before resolving the issue of a commercial brand is problematic. I suppose it will be argued that these folks intend to make it an Eclipse brand in the future, but those discussions did not take place in the open so I can't comment on how they were resolved. In any case, the approach of publishing a proposal using what is currently a commercial brand is something that the community does question and the foundation perhaps should be seen to be acting strongly to protect the Eclipse brand from this type of confusion. Note that I didn't say they aren't, I'm saying there's a perception problem.

In the end, all this has served to create confusion in the community. The community really doesn't know what it will get. It seems we won't be seeing profiled UML nor a domain specific language. We're not sure we'll even get an EMOF/Ecore-based model. So we don't know if any existing modeling technologies, such as JET, XPand, ATL, QVT, OCL, transaction, validation, and so on will be applicable. The lack of clear answers to questions raised on the newsgroup leaves us a bit doubtful that good intentions will prevail, though I don't question the good intentions themselves since Eric is quite clearly a very nice person with whom I'd love to work, but development costs have a way to interfering with good intentions.


The creation review slides talk about Tigerstripe being a framework for "commercial Cisco extensions" yet it says nothing about the nature of the extensibility mechanisms. The modeling community really wants to understand how this technology will fit in and to date, we've only seen the proposal shift itself shift out from under us; that doesn't inspire confidence. The modeling project is already providing a framework for model driven engineering, but the slides claim the same without qualification as to the scope. They're vague about what kind of integration with the modeling project Tigerstripe will provide. Certainly there is no need for another UML model nor for class and instance diagrams, because those things are already supported.

While Eclipse doesn't have rules to prevent competition, nor should it, Eclipse is founded on principles of cooperation to share costs and to unify communities, so this proposal goes a little against the general grain. Though I suppose it's no longer claiming to provide a competitive UML model, but rather a subset because UML itself is too complex. To rant on a bit more, it's not clear what a headless build environment is; I imagine Eclipse already has that. Nor is it clear what a plugin engine is; I wonder how it relates to the model workflow engine. If the model is UML2 then it's unclear why there is a need for UML import and export. It is simply not clear that there is a real plan in place to reuse UML2 and given the lack of answers to specific questions (i.e., if Tigerstripe didn't use UML2 two years ago why will it start using it now?) there is room for doubt. It's also not clear what an XML export plugin is all about; EMF already supports XML serialization for any model, so the relationship to that is unclear. And finally, it would have been good if someone had explained that the V2.3 goal in the proposal is not possible with Eclipse's incubation and version numbering rules.

I feel like I'm being a total downer on this subject and that's made me repeatedly question my own motivations. Am I just being defensive or even worse protectionist? Am I failing to be open minded? Goodness knows that wouldn't be the first time. Is it reasonable to vote -1 on a creation review and not even give folks a chance to prove themselves? Certainly there is value in an industry vertical modeling technology, but there are an awful lot of questions and I think the situation has been handled poorly with a little too much emphasis on driving forward without much time proper reflection. Sorry for being such a downer...

It's probably not politically correct to question whether Cisco should consider coughing up Strategic Developer costs to help pay for the infrastructure it will use and for the IP resource it will consume. But I think such meta questions also need to be asked. Much smaller organizations have shown more financial commitment toward Eclipse than has Cisco to date.

So I'm trying to keep an open mind and to be transparent with the hope that my heart is in the right place.


As such, I will appreciate any comments folks might have in terms of advice on how this should be handled. I'm just not sure and I'm second guessing myself so I will try to accept criticism graciously. Fire away!

Please Reinstate The Top Contributor Award

Nominations for this year's Eclipse Community Awards are open but unfortunately the Top Contributor award has gone absent without leave. I sent Ruby out searching for it:


After some effort, she and Amber rooted out 213601. Apparently there was some confusion about the distinction between Top Committer verses Top Contributor, but that just left Amber perplexed:


She figured that both these terms are quite clearly defined and that the definitions are well understood by the community. Given that a picture is worth a thousand words, here is how Top Committer is defined pictorially for the illiterate:


I'll leave it as an exercise for the reader to imagine what the Top Contributor award would look like pictorially based on extrapolating from the definition of Top Committer which "Recognizes an Eclipse committer who best exemplifies support for the community through newsgroups, Bugzilla, white papers, conference presentations, blogs and other forums." It seems obvious that Top Contributor "Recognizes an Eclipse contributor who best exemplifies support for the community through newsgroups, Bugzilla, white papers, conference presentations, blogs and other forums."

I suspect that the confusing part in previous years was that committers could not vote on the committer award and that the community at large could not vote on the contributor award (if my recollection is accurate). That seemed odd to me because with regard to the platform project, I am a community member, not a committer, and if I provide patches and a test case, then I'm a contributor to the platform project. An excellent example of this is dual aspect is Tom Schindl who is a committer on the platform UI, but as far as I'm concerned, from EMF perspective he is a top contributor because of 209434, 209435, and 211340. So I think that both committers and contributors ought to be able to vote for both awards and that the biggest point of confusion is likely the dual role folks play within the community. But that's just another aspect we ought to encourage. Let's not leave contributors out in the cold.


I don't think the distinction between committer and contributor is the least bit confusing and certainly doesn't require two paragraphs to explain well; just read the IP policy for clear definitions of these terms. Once the terms are well understood, the reason for an award for each seems self evident. Nick made an effort to provide the requisite two paragraphs to get Bjorn's +1, and while Ian thought the distinction of "committers are paid but contributors are not" was useful, I'm with Remy on this one: a giant -1 on the notion that renumeration or lack there of is a useful distinguishing characteristic. There are an awful lot of people committing or contributing valuable results simply based on their passion for Eclipse without that work directly earning them a single extra penny. People like Martin Taal, Eike Stepper, Sandro Boehme, Bernd Kolb and others (whom I won't mention because they've not contributed their photos on the EMFT contributors page despite reminders; expect to be nagged further) are perfect examples of committers who aren't being paid by anyone for their commits.

Given the high value we committers place on the community at large and especially on the contributing subset within that community, we most certainly ought to have an award to recognize those who best exemplify this valuable trait.

Please don't take our sunshine away!

Thursday, December 6, 2007

No Good Deed Goes Unpunished

I'm a firm believer in the old adage that "No good deed goes unpunished." Why is that you might ask? Well, it's because a good deed is clearly done with good intent and of course we all know that the road to hell is paved with good intentions. So it follows that a good deed is often the first step on the way to hell. Of course most roads in the Eclipse community are paved with good intentions, so I certainly don't think they're all leading straight to hell, but one misstep and you could be well on your way. Goodness knows there are enough people watching for a misstep. In any case, I'd like to think that if hell froze over, it would look like this:


One always hopes that others will recognize good intentions for what they are and that when the actual results of well intended efforts do not match precisely the intent, that the intent is not forgotten.

I've often been told that I color my language with too much emotion and I'm sure that's true. It's a common failing of those with passion to misdirect that passion when sensibilities are violated. One might call that irresponsible, but that's using emotional language. It's always a good idea to focus on criticizing the ideas rather than criticizing people directly. Its also important to keep in mind that none of us really like personal criticism, or any kind of criticism for that matter. As such, even constructive criticism is not always well received despite the good intentions of those dishing it out. This basic failing in human nature makes it extremely difficult to influence change without giving others cause for taking offense.

I write this blog to help remind myself and others to think carefully when dishing out criticism. It's best to state all criticism in the form of a positive suggestions for improvements. Always make it clear your intentions are good. You're still likely to end up on the road to hell, but ask yourself this: What are the roads that lead away from hell paved with?


I'll climb down off of my high horse now---or is that my soap box? it's so hard to tell--- before someone knocks me off....

Tuesday, December 4, 2007

Winter's Icy Grip

Sunday night we had freezing rain north of Toronto. We never had such things in Vancouver where I grew up, just lots of normal rain. Predictions of freezing rain always make me worried about the garden, but there was little damage and much beauty. Diversity of weather certainly has its points of interest. This shot of a berry locked away in ice was my favorite for the day.


Monday was also the day that the Friends of Eclipse program was launched. As a committer representative on the board, I received advanced notice on Sunday. This is a program the committer representatives asked the foundation to look into setting up, so naturally I was thrilled with Ian's results and at the opportunity to be one of the first to demonstrate my friendship with my wallet, not just with my words. I even outbid Mike, but then the stakes quickly became to high for me! (I must say, Jeff is such a competitive guy!) Have a look at how quickly the donor list is growing! There's even a kind remark about modeling. How nice is that?

I'm proud to display a Friends of Eclipse logo on my blog home page. Thanks to Nathan, it's not just a one size fits all logo either, but rather is available in small, medium, and large. I suppose pride is a sin, so I should say I'm honored to display it. Eclipse has been my friend for a long time, so it's nice to know that now I'm Eclipse's friend...

Today the sun came out again. The combination of sun and ice is quite a thing!


I love a sunny day with fresh snow. You can see from all the ice on my blue spruce offset so nicely by the blue sky why I might worry about damage. It's a lot of extra weight to bear!


Even the girls think the snow is kind of cool, but I have to clear a bit of the backyard for them since they tend to disappear in a foot of snow.


I've not been busy just taking pictures either! I've been working on something that's kind of cool and also relatively simple. Have you ever heard of a substitution group? I see I've piqued your curiosity. (Just ask her where the ducky is and she'll give you this same look!)



A substitution group is an XML Schema thing and is what I call syntactic sugar because it's primary purpose is to make your XML serialization look pretty by allowing the instance to avoid the use of xsi:type. Though goodness knows it's beyond me why anyone cares that something as ugly as XML should be made slightly less ugly when it's barely human readable in the first place, but hey, there are an awful lot of people who are quite obsessed with the prettiness of their XML.

So here's the basic idea. Suppose I defined a type Resource with two subtypes, Folder and File, where a Folder has a list of members of type Resource. To round it out, we might define a FileSystem as having a list of folders. We could define that in XML Schema like this:
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
xmlns:resource="http://www.example.com/resource"
targetNamespace="http://www.example.com/resource">

<xsd:element name="fileSystem"
type="resource:FileSystem"/>
<xsd:complexType name="FileSystem">
<xsd:sequence>
<xsd:element name="folder"
ecore:name="folders" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>

<xsd:element name="member"
ecore:name="members" type="resource:Resource"/>
<xsd:complexType name="Resource" abstract="true">
<xsd:attribute name="name" type="xsd:string"/>
</xsd:complexType>

<xsd:complexType name="Folder">
<xsd:complexContent>
<xsd:extension base="resource:Resource">
<xsd:sequence>
<xsd:element ref="resource:member"
ecore:name="members" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>

<xsd:complexType name="File">
<xsd:complexContent>
<xsd:extension base="resource:Resource">
<xsd:sequence>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>

</xsd:schema>
Generating the EMF code for the above, we could use the generated API to create an instance like this:
Resource resource =
resourceSet.createResource
(URI.createURI("http:///My.resource"));
DocumentRoot documentRoot =
ResourceFactory.eINSTANCE.createDocumentRoot();
FileSystem fileSystem =
ResourceFactory.eINSTANCE.createFileSystem();
documentRoot.setFileSystem(fileSystem);
Folder folder1 =
ResourceFactory.eINSTANCE.createFolder();
fileSystem.getFolders().add(folder1);
folder1.setName("folder1");
File file1 = ResourceFactory.eINSTANCE.createFile();
file1.setName("file1");
folder1.getMembers().add(file1);
resource.getContents().add(documentRoot);
resource.save(System.out, null);
ByteArrayOutputStream out = new ByteArrayOutputStream();
resource.save(out, null);
Resource resource2 =
resourceSet.createResource
(URI.createURI("http:///My2.resource"));
resource2.load
(new ByteArrayInputStream(out.toByteArray()), null);
DocumentRoot loadedDocumentRoot =
(DocumentRoot)resource2.getContents().get(0);
The resulting serialization looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<resource:fileSystem
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:resource="http://www.example.com/resource">
<folder xsi:type="resource:Folder" name="folder1">
<resource:member xsi:type="resource:File" name="file1"/>
</folder>
</resource:fileSystem>
To our horror, it's full of xsi:types! Clearly it's metadata and it offends our sensibilities to see such metadata mixed in our data. Of course the element and attribute names are metadata too, and xsi:type is something that any conforming XML processor must handle, but let's not cloud an emotional issue with facts.

You might wonder why these xsi:types are even needed? If you think about it, when you seen an element named member, you won't know if it's a folder or a file, so you won't know what elements and attributes to expect in addition to those you would expect for a Resource. For EMF such information is important too because we need to create the right type of object.

To deal with this type of issue, XML Schema defines the notion of a substitution group. Here's the idea. We define new elements named folder and file and declare that they are in the substitution group for the member element.
<xsd:element name="folder"
substitutionGroup="resource:member"
type="resource:Folder"/>
<xsd:element name="file"
substitutionGroup="resource:member"
type="resource:File"/>
Now, where ever a member element may appear, a folder or file element can be substituted. And of course, once we see that element, we'll know the type of that element and hence won't need an xsi:type. If we are feeling particularly clever, we might even declare the member element abstract because Resource is abstract and hence we'd never expect to see a member element.
<xsd:element name="member"
ecore:name="members"
type="resource:Resource"
abstract="true"/>
So now we can go back, generate our API again, and try to rerun our previous example, which ends up failing with the incredibly helpful runtime exception that says
Invalid entry feature 'Folder.members'
Naturally we scurry off to the EMF newsgroup where it's explained to us that the members feature is read only because the members element is abstract. We must specify a "document root" feature in some horrible feature map that we didn't notice was generated in the Folder interface and that we don't know how to use.
FeatureMap getMembersGroup();
Finally we come to realize, based on the helpful advice, that we must change our example like this:
// folder1.getMembers().add(file1);
folder1.getMembersGroup().add
(ResourcePackage.Literals.DOCUMENT_ROOT__FILE, file1);
Woo hoo. Finally we have it producing what we want.
<?xml version="1.0" encoding="UTF-8"?>
<resource:fileSystem
xmlns:resource="http://www.example.com/resource">
<resource:folder name="folder1">
<resource:file name="file1"/>
</resource:folder>
</resource:fileSystem>
But it's kind of a bitter sweet victory because clearly our syntactic sugar has turned into semantic rat poison. So many folks won't quite be satisfied and some I know have even gone through great lengths to suppress the rat poison from the API and to write clever code that figures if you add a File to the getMembers() list, you really must mean you want to use the document root's file feature since that's the only choice available. It's clear that this kind of cleverness could be handled by the serializer itself, so I've added support for XMLResource.OPTION_ELEMENT_HANDLER along with an XML Schema annotation to eliminate the semantic rat poison:
<xsd:schema
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
ecore:ignoreSubstitutionGroups="true"
If we reload the schema and regenerate the API, it goes back to like we had it before. Then we can change the code to how we had it and we can add the new option to the regenerated resource factory's createResource method:
result.getDefaultSaveOptions().put
(XMLResource.OPTION_ELEMENT_HANDLER,
new ElementHandlerImpl(false));
The result is that we get the same sugary sweet serialization without the rotten decay in the API.

While I was at it, I thought I might as well look at eliminating the need to use a document root, since that rubs some people the wrong way. Often folks don't understand why it even exists and it's effectively just another example of semantic rat poison. As modelers, we're quite used to the concept of having an object that is an instance of some type, and that corresponds directly to having an instance of some type in XML schema. But the root of an XML document doesn't specify a type name, it specifies an element name. Hence a DocumentRoot is like an invisible root object that has features to contain the real root object; the name of that containing feature determines the root element's name. So clearly if we can deduce a substitution group element during serialization based on the type of object being serialized, we can also deduce a correct root element name in a very similar way. The new element handler option supports that as well, so all that remains is to be able to suppress the document root during load and then we can pretend that document roots don't exist at all.

The new option XMLResource.OPTION_SUPPRESS_DOCUMENT_ROOT can be used to suppress loading of a document root. We just need to add it to your generate createResource method.
result.getDefaultLoadOptions().put
(XMLResource.OPTION_SUPPRESS_DOCUMENT_ROOT,
Boolean.TRUE);
Then we can rewrite our example to omit the document root.
Resource resource =
resourceSet.createResource
(URI.createURI("http:///My.resource"));
FileSystem fileSystem =
ResourceFactory.eINSTANCE.createFileSystem();
Folder folder1 = ResourceFactory.eINSTANCE.createFolder();
fileSystem.getFolders().add(folder1);
folder1.setName("folder1");
File file1 = ResourceFactory.eINSTANCE.createFile();
file1.setName("file1");
folder1.getMembers().add(file1);
resource.getContents().add(fileSystem);
resource.save(System.out, null);
ByteArrayOutputStream out = new ByteArrayOutputStream();
resource.save(out, null);
Resource resource2 =
resourceSet.createResource
(URI.createURI("http:///My2.resource"));
resource2.load
(new ByteArrayInputStream(out.toByteArray()), null);
FileSystem loadedFileSystem =
(FileSystem)resource2.getContents().get(0);
It's thing of beauty. Sugar without decay.

Here's a final image to capture your imagination. It's like a Rorschach inkblot test. What do you see in this picture?