This wiki is locked. Future workgroup activity and specification development must take place at our new wiki. For more information, see this blog post about the new governance model and this post about changes to the website.
Date: 2 Aug 2012
Time: 7:00 AM Pacific, 10:00 AM Eastern, 3:00 PM UK, 4:00 PM Frankfurt, 5:00 PM Haifa, 8:30 PM Bangalore
Call In Number: (emailed)
Participation request: contact JimConallen


  1. Updates on Core Activities
  2. Discuss the creation of AM sub groups for specific domains (i.e. BPMN, UML, ...)
  3. Continue discussion of Diagram resource type.
  4. Continue discussion of migrating vocabularies and resource versions.


Regrets: Eldad Palachi, Eran Gery, Jean-Louis Marechaux, Sandeep Kholi

Atendees: John Crouchley, Yuriy Yermakov, Clyde D Icuspit, Steve Speicher, Jim Conallen


We brought up John on the current discussions regarding the diagram resource. His initial concern was over its relevance. For SVG diagram resources much of the information that is in this proposed resource is already in the SVG (to support the highlight and click through scenarios). But for raster images like PNG, this information is not present in the image rendering.

John asked if diagram views could contain children views. He suggested scenarios where hiding, or moving a symbol or node would really mean it and all its children.

In our discussions we reminded ourselves several times that these discussions are all for generic diagrams and visualizations, and that we should not be thinking about the semantics of any type diagram. We did agree that most diagrams in the architecture space are node/arc diagrams where the diagram contains things connected to other things.

The whole goal of these discussions are to provide the client with some additional information that could be used to help make diagrams, especially large complicated ones more consumable.

John also suggested that we should have a separate concept for connectors. Jim agreed to update the proposed resource definition to include this.

We discussed ordering, and Steve said that at the core there is no definitive way to order or sequence things. We proposed adding an order property to the view resource that a client would use to determine the order in overlapping views.

Topic revision: r1 - 02 Aug 2012 - 15:30:24 - JimConallen
This site is powered by the TWiki collaboration platform Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use
Ideas, requests, problems regarding this site? Send feedback