polarsys.arcon/proposal.html - www.eclipse.org/proposals - Git at Google

 <!--
 	This document is provided as a template along with some guidance for creating
 	your project proposal. This is just a template. Feel free to change it as
 	you see fit (add sections, remove section). We feel, however, that the
 	suggestions represented in this document represent the reasonable minimum
 	amount of information to move forward.

 	Please keep the formatting in this document simple. Please do not edit
 	this document in Microsoft Word as it adds huge piles of markup that make
 	it difficult to restyle.

 	More information is available here:

 	http://wiki.eclipse.org/Development_Resources/HOWTO/Pre-Proposal_Phase

 	Direct any questions about this template to emo@eclipse.org
  -->

 <html><html>
 <head>

 <!--
 	Include the title here. We will parse it out of here and include it on the
 	rendered webpage. Do not duplicate the title within the text of your page.
  -->

 <title>ArCon</title>
 </head>

 <!--
 	We make use of the 'classic' HTML Definition List (dl) tag to specify
 	committers. I know... you haven't seen this tag in a long while...
  -->

 <style>
 dt {
 display: list-item;
 list-style-position:outside;
 list-style-image:url(/eclipse.org-common/themes/Phoenix/images/arrow.gif);
 margin-left:16px;
 }
 dd {
 margin-left:25px;
 margin-bottom:5px;
 }
 </style>

 <body>
 <p>The ArCon project is a proposed open source project under the PolarSys Container Project</a>.</p>

 <!--
 	The communication channel must be specified. Typically, this is the
 	"Proposals" forum. In general, you don't need to change this.
  -->
 <p>This proposal is in the Project Proposal Phase (as defined in the
 Eclipse Development Process) and is written to declare its intent and
 scope. We solicit additional participation and input from the Eclipse
 community. Please send all feedback to the
 <a href="http://www.eclipse.org/forums/eclipse.proposals">Eclipse Proposals</a>
 Forum.</p>

 <h2>Background</h2>

 <p>
 Work with architectural validation of a system model can be a tedious work and
 unless you are very meticulous, it is easy to make a mistake, espacially if it is
 a large system.
 </p>

 <p>
 With the help of ArCon, the system architect doesn't have to check every version
 of the system model against the architectural rules to see if the system model is
 following the predefined rules.
 Instead, the developer can use ArCon to automatically check if the system model is conforming to
 the architectural rules.
 This way the project is saving money and time with the conformity check, and is
 avoiding possible mistakes from manually checking.
 </p>


 <h2>Scope</h2>

 <!--
 	All projects must have a well-defined scope. Describe, concisely, what
 	is in-scope and (optionally) what is out-of-scope. An Eclipse project
 	cannot have an open-ended scope.
  -->
   <p>
   ArCon is integrated with Eclipse and supports model developers in following given
   architectural rules for the developed system. ArCon interprets an architectural metamodel,
   created in UML, and extracts rules. The extracted rules are applied in an analysis of the
   developed system model. ArCon currently supports the developer in a reactive way resulting in
   a list of issues presenting violations to the rules. The scope also includes a
   proactive way of supporting the developer by presenting only allowed options when adding
   new elements and element properties. ArCon utilizes the Eclipse GUI and target modeling
   tools/editors are for now Papyrus and Topcased.
   </p>

 <h2>Description</h2>


 <!--
 	Describe the project here. Be concise, but provide enough information that
 	somebody who doesn't already know very much about your project idea or domain
 	has at least a fighting chance of understanding its purpose.
  -->
  <p>
 ArCon is a tool for architecture conformance validation of systems modelled in UML/SysML.
 ArCon provides an easy to use and intuitive way of specifying architectural rules and
 a mechanism to automatically validate that the system under development conforms to the
 rules specified. ArCon validates a model and detect errors in the model breaking predefined
 rules. ArCon is primarily intended for, but not limited to, products of high complexity
 and/or subject to long term maintenance needs.
 </p>

 <h4>What problem does ArCon solve?</h4>
 <p>
 The traditional process (in architecture driven development) starts with the definition of
 the architecturally significant requirements; these are essentially the quality and
 non-functional requirements. The architect undertakes the architectural design with
 addressing the architecture requirements. Essentially the architect makes a number of
 decisions on how the system should be designed in order to ensure that architectural
 requirements are fulfilled. The results is typically a high-level structure of the
 system, a framework of base-classes implementing the communication infrastructure
 of the system, and a set of structural and behavioural rules to follow in the design
 the components that populates the system model. The high level structure and the
 framework goes into the system-model and the rules are specified in a textual document.
 During the architectural design, the architecture is regularly validated against the
 architecture requirements and if necessary the requirements are renegotiated. When the
 architecture has been validated against its requirements, the next development phase
 begins. In this phase the system is developed in a number of increments with increasing
 functionality. Each development increment begins with a definition of the requirements
 to be implemented in the increment. Each development team then does a preliminary
 design defining how the required functionality is allocated to new and existing
 components according to the architectural design rules. Before the development team
 is allowed to start the detailed design of the components, the preliminary design must
 pass the architectural review. In the architectual review the architect checks that the
 design does not violate the architectural design rules. During preliminary design and
 detailed design the architect supports the development teams and guides them in how to
 follow the architectural design rules. If any problems with the architecture revealed
 during preliminary design necessitate changes to the architecture, these changes are
 done by the architect in parallel with the development work.
 </p>
 <p>
 The problem with this process is that manual enforcement of the architectural design rules
 takes a lot of time from the architect. This makes architectural enforcement a bottleneck
 in MDD projects that leads to a plethora of problems.
 To address these problems the method to model architectural design rules that is supported
 by ArCon has been developed by Combitech with support from researchers at the University
 of Sk&ouml;vde and the University of Limerick. Using this approach we get a process where the
 manual architectural reviews are eliminated.
 This removes the architect as a bottleneck in the development and increases significantly
 the amount of time available for guiding the teams. Anther difference is that the
 architect models the architectural design rules instead of expressing them as informal
 text which also increases the quality of the architecture and makes it simpler to communicate.
 </p>
 <p>
 The task of ArCon is basically split into two major activities:</p>
 <ul>
 	<li>Read the architecture meta model pointed out from the system model and interpret the
 	expressed rules.</li>
 	<li>Read and traverse the system model which shall conform to the rules and analyse
 	conformance. Report detected violations to the developer.</li>
 </ul>
 The report is presented in the console window but shall also be indicated by markers in
 the model browser or diagram.

 <h2>Why Eclipse?</h2>

 <!--
 	Answer these two questions:	What value does this project bring to the Eclipse
 	community? What value do you expect to obtain from hosting your project at Eclipse?

 	What value do you get by having your project at Eclipse over and above the value
 	of hosting at Eclipse Labs?
  -->
 <p>
 Open source tools in general and Eclipse based ones in particular are becoming more and
 more interesting solutions for many companies, large and small. ArCon was originally
 developed to operate with a commersial modeling tool, but in pace with increasing
 capability of Eclipse based UML/SysML modeling, such as Topcased/Papyrus, the opportunity
 to provide a fully open source based tool chain within the scope of Polarsys has become
 interesting. The task of automatic architecture conformance validation of systems developed
 in UML (or SysML) against rules expressed in UML has not been concretely adressed before
 in Eclipse. The easy to to understand rules (for UML familiar developers) will broaden the
 offer of Eclipse to the user community.
 </p>
 <p>
 As companies now are getting interested in using ArCon they would be more comfortable with
 the long term ambitions and sustainability of ArCon if it is adopted and hosted by Eclipse.
 Some companies se Eclipse affiliation as a demand for start using an open source tool seriously.
 ArCon will be more visible and it will increase the possibility to build both user and developer
 communities around it.
 </p>
 <h2>Initial Contribution</h2>

 <!--
 	Projects are expected to arrive at Eclipse with existing code.

 	Describe the existing code that will be contributed to the project. Please provide
 	a couple of paragraphs describing the code with modest detail, including important
 	information like code ownership (who holds the copyright?), and some consideration
 	of community that exists around the code. Include a listing of third-party libraries
 	and associated licenses.
  -->
 <p>
 The initial contribution of ArCon would consist of the core codebase that can be viewed
 <a href="http://code.google.com/a/eclipselabs.org/p/arcon/source/browse">here</a>
 and the ArCon documentation, design model and test models which can be viewed
 <a href="http://code.google.com/a/eclipselabs.org/p/arcon/downloads/list">here</a>.
 </p>

 <p>
 This code was developed within a group of commiters and is licensed under Eclipse Public License (EPL 1.0).
 </p>
 <p>
 <b>Overall design of the code</b>
 <br>
 At top level the project is divided into three packages:
 </p>

 <p>
 <b>backboneCode:</b> This package contains classes that are used to extract and traverse
 the UML models, or store the information about
 which rules that applies to which element for the conformance check and in the end reports it all
 to the user via the Eclipse GUI. The report is prepared by traversing the system model elements
 to see if they deviate from the rules.
 </p>

 <p>
 <b>eArCon.applications:</b> This package contains the main class. It will make use of the other
 classes to do the conformance check.
 </p>

 <p>
 <b>rulePackage:</b> In this package, classes are oriented towards the differnt steps in the conformance check
 of the system model. It's everything from defining the parameters used to specify the rules for
 each UML element to later validating the the system model against the rules from the achitectural model
 </p>

 <h2>Legal Issues</h2>

 <!--
 	Please describe any potential legal issues in this section. Does somebody else
 	own the trademark to the project name? Is there some issue that prevents you
 	from licensing the project under the Eclipse Public License? Are parts of the
 	code available under some other license? Are there any LGPL/GPL bits that you
 	absolutely require?
  -->
  <p>
  There are no known legal issues.
  </p>

 <h2>Committers</h2>

 <!--
 	List any initial committers that should be provisioned along with the
 	new project. Include affiliation, but do not include email addresses at
 	this point.
  -->

 <p>The following individuals are proposed as initial committers to the project:</p>

 <dl>
 	<dt>Gert Johansson, Combitech (lead)</dt>
 	<dt>Anders Mattsson, Husqvarna (lead)</dt>
 	<dt>Johan Norberg, Combitech</dt>
 	<dt>Emil Fridell, Combitech</dt>
 	<dt>Carl-Oscar Varnander, Combitech</dt>
 	<dt>Leila Azari, Combitech</dt>
 	<dt>Rikard Soler Avellen, Combitech</dt>
 	</dd>
 </dl>

 <p>We welcome additional committers and contributions.</p>

 <!--
 	Describe any initial contributions of code that will be brought to the
 	project. If there is no existing code, just remove this section.
  -->

 <h2>Mentors</h2>

 <!--
 	New Eclipse projects require a minimum of two mentors from the Architecture
 	Council. You need to identify two mentors before the project is created. The
 	proposal can be posted before this section is filled in (it's a little easier
 	to find a mentor when the proposal itself is public).
  -->

 <p>The following Architecture Council members will mentor this
 project:</p>

 <ul>
 	<li>Michael Scharf</li>
 	<li>Wayne Beaton</li>
 </ul>

 <h2>Interested Parties</h2>

 <!--
 	Provide a list of individuals, organisations, companies, and other Eclipse
 	projects that are interested in this project. This list will provide some
 	insight into who your project's community will ultimately include. Where
 	possible, include affiliations. Do not include email addresses.
  -->

 <p>The following individuals, organisations, companies and projects have
 expressed interest in this project:</p>

 <ul>
 	<li>Dominique Toupin, Ericsson</li>
 	<li>Ronan Barrett, Ericsson</li>
 	<li>Andreas Jakobik, Ericsson</li>
 	<li>Patrik Nandorf, Ericsson </li>
 	<li>Stefan Grufman, Husqvarna</li>
 	<li>Bo Hagerf, Combitech</li>
 	<li>Erik Herzog, Saab</li>
 	<li>Henrik Andersson, Saab</li>
 	<li>Jonas Andersson, Volvo</li>
 	<li>Tobias den Braver, Saab EDS</li>
 	<li>Bj&ouml;rn Lundell, University of Sk&ouml;vde</li>
 	<li>Airbus</li>
 </ul>

 <h2>Project Scheduling</h2>

 <!--
 	Describe, in rough terms, what the basic scheduling of the project will
 	be. You might, for example, include an indication of when an initial contribution
 	should be expected, when your first build will be ready, etc. Exact
 	dates are not required.
  -->
 <p>
 The ArCon project intends to have a first code contribution ready by June 1st, and
 hopefully the first builds to be ready soon therafter.
 </p>

 <h2>Changes to this Document</h2>

 <!--
 	List any changes that have occurred in the document here.
 	You only need to document changes that have occurred after the document
 	has been posted live for the community to view and comment.
  -->

 <table>
 	<tr>
 		<th>Date</th>
 		<th>Change</th>
 	</tr>
 	<tr>
 		<td>25-February-2013</td>
 		<td>Document created</td>
 	</tr>
 </table>
 </body>
 </html>
	<!--
	This document is provided as a template along with some guidance for creating
	your project proposal. This is just a template. Feel free to change it as
	you see fit (add sections, remove section). We feel, however, that the
	suggestions represented in this document represent the reasonable minimum
	amount of information to move forward.

	Please keep the formatting in this document simple. Please do not edit
	this document in Microsoft Word as it adds huge piles of markup that make
	it difficult to restyle.

	More information is available here:

	http://wiki.eclipse.org/Development_Resources/HOWTO/Pre-Proposal_Phase

	Direct any questions about this template to emo@eclipse.org
	-->

	<html><html>
	<head>

	<!--
	Include the title here. We will parse it out of here and include it on the
	rendered webpage. Do not duplicate the title within the text of your page.
	-->

	<title>ArCon</title>
	</head>

	<!--
	We make use of the 'classic' HTML Definition List (dl) tag to specify
	committers. I know... you haven't seen this tag in a long while...
	-->

	<style>
	dt {
	display: list-item;
	list-style-position:outside;
	list-style-image:url(/eclipse.org-common/themes/Phoenix/images/arrow.gif);
	margin-left:16px;
	}
	dd {
	margin-left:25px;
	margin-bottom:5px;
	}
	</style>

	<body>
	<p>The ArCon project is a proposed open source project under the PolarSys Container Project</a>.</p>

	<!--
	The communication channel must be specified. Typically, this is the
	"Proposals" forum. In general, you don't need to change this.
	-->
	<p>This proposal is in the Project Proposal Phase (as defined in the
	Eclipse Development Process) and is written to declare its intent and
	scope. We solicit additional participation and input from the Eclipse
	community. Please send all feedback to the
	<a href="http://www.eclipse.org/forums/eclipse.proposals">Eclipse Proposals</a>
	Forum.</p>

	<h2>Background</h2>

	<p>
	Work with architectural validation of a system model can be a tedious work and
	unless you are very meticulous, it is easy to make a mistake, espacially if it is
	a large system.
	</p>

	<p>
	With the help of ArCon, the system architect doesn't have to check every version
	of the system model against the architectural rules to see if the system model is
	following the predefined rules.
	Instead, the developer can use ArCon to automatically check if the system model is conforming to
	the architectural rules.
	This way the project is saving money and time with the conformity check, and is
	avoiding possible mistakes from manually checking.
	</p>


	<h2>Scope</h2>

	<!--
	All projects must have a well-defined scope. Describe, concisely, what
	is in-scope and (optionally) what is out-of-scope. An Eclipse project
	cannot have an open-ended scope.
	-->
	<p>
	ArCon is integrated with Eclipse and supports model developers in following given
	architectural rules for the developed system. ArCon interprets an architectural metamodel,
	created in UML, and extracts rules. The extracted rules are applied in an analysis of the
	developed system model. ArCon currently supports the developer in a reactive way resulting in
	a list of issues presenting violations to the rules. The scope also includes a
	proactive way of supporting the developer by presenting only allowed options when adding
	new elements and element properties. ArCon utilizes the Eclipse GUI and target modeling
	tools/editors are for now Papyrus and Topcased.
	</p>

	<h2>Description</h2>


	<!--
	Describe the project here. Be concise, but provide enough information that
	somebody who doesn't already know very much about your project idea or domain
	has at least a fighting chance of understanding its purpose.
	-->
	<p>
	ArCon is a tool for architecture conformance validation of systems modelled in UML/SysML.
	ArCon provides an easy to use and intuitive way of specifying architectural rules and
	a mechanism to automatically validate that the system under development conforms to the
	rules specified. ArCon validates a model and detect errors in the model breaking predefined
	rules. ArCon is primarily intended for, but not limited to, products of high complexity
	and/or subject to long term maintenance needs.
	</p>

	<h4>What problem does ArCon solve?</h4>
	<p>
	The traditional process (in architecture driven development) starts with the definition of
	the architecturally significant requirements; these are essentially the quality and
	non-functional requirements. The architect undertakes the architectural design with
	addressing the architecture requirements. Essentially the architect makes a number of
	decisions on how the system should be designed in order to ensure that architectural
	requirements are fulfilled. The results is typically a high-level structure of the
	system, a framework of base-classes implementing the communication infrastructure
	of the system, and a set of structural and behavioural rules to follow in the design
	the components that populates the system model. The high level structure and the
	framework goes into the system-model and the rules are specified in a textual document.
	During the architectural design, the architecture is regularly validated against the
	architecture requirements and if necessary the requirements are renegotiated. When the
	architecture has been validated against its requirements, the next development phase
	begins. In this phase the system is developed in a number of increments with increasing
	functionality. Each development increment begins with a definition of the requirements
	to be implemented in the increment. Each development team then does a preliminary
	design defining how the required functionality is allocated to new and existing
	components according to the architectural design rules. Before the development team
	is allowed to start the detailed design of the components, the preliminary design must
	pass the architectural review. In the architectual review the architect checks that the
	design does not violate the architectural design rules. During preliminary design and
	detailed design the architect supports the development teams and guides them in how to
	follow the architectural design rules. If any problems with the architecture revealed
	during preliminary design necessitate changes to the architecture, these changes are
	done by the architect in parallel with the development work.
	</p>
	<p>
	The problem with this process is that manual enforcement of the architectural design rules
	takes a lot of time from the architect. This makes architectural enforcement a bottleneck
	in MDD projects that leads to a plethora of problems.
	To address these problems the method to model architectural design rules that is supported
	by ArCon has been developed by Combitech with support from researchers at the University
	of Skövde and the University of Limerick. Using this approach we get a process where the
	manual architectural reviews are eliminated.
	This removes the architect as a bottleneck in the development and increases significantly
	the amount of time available for guiding the teams. Anther difference is that the
	architect models the architectural design rules instead of expressing them as informal
	text which also increases the quality of the architecture and makes it simpler to communicate.
	</p>
	<p>
	The task of ArCon is basically split into two major activities:</p>
	<ul>
	<li>Read the architecture meta model pointed out from the system model and interpret the
	expressed rules.</li>
	<li>Read and traverse the system model which shall conform to the rules and analyse
	conformance. Report detected violations to the developer.</li>
	</ul>
	The report is presented in the console window but shall also be indicated by markers in
	the model browser or diagram.

	<h2>Why Eclipse?</h2>

	<!--
	Answer these two questions: What value does this project bring to the Eclipse
	community? What value do you expect to obtain from hosting your project at Eclipse?

	What value do you get by having your project at Eclipse over and above the value
	of hosting at Eclipse Labs?
	-->
	<p>
	Open source tools in general and Eclipse based ones in particular are becoming more and
	more interesting solutions for many companies, large and small. ArCon was originally
	developed to operate with a commersial modeling tool, but in pace with increasing
	capability of Eclipse based UML/SysML modeling, such as Topcased/Papyrus, the opportunity
	to provide a fully open source based tool chain within the scope of Polarsys has become
	interesting. The task of automatic architecture conformance validation of systems developed
	in UML (or SysML) against rules expressed in UML has not been concretely adressed before
	in Eclipse. The easy to to understand rules (for UML familiar developers) will broaden the
	offer of Eclipse to the user community.
	</p>
	<p>
	As companies now are getting interested in using ArCon they would be more comfortable with
	the long term ambitions and sustainability of ArCon if it is adopted and hosted by Eclipse.
	Some companies se Eclipse affiliation as a demand for start using an open source tool seriously.
	ArCon will be more visible and it will increase the possibility to build both user and developer
	communities around it.
	</p>
	<h2>Initial Contribution</h2>

	<!--
	Projects are expected to arrive at Eclipse with existing code.

	Describe the existing code that will be contributed to the project. Please provide
	a couple of paragraphs describing the code with modest detail, including important
	information like code ownership (who holds the copyright?), and some consideration
	of community that exists around the code. Include a listing of third-party libraries
	and associated licenses.
	-->
	<p>
	The initial contribution of ArCon would consist of the core codebase that can be viewed
	<a href="http://code.google.com/a/eclipselabs.org/p/arcon/source/browse">here</a>
	and the ArCon documentation, design model and test models which can be viewed
	<a href="http://code.google.com/a/eclipselabs.org/p/arcon/downloads/list">here</a>.
	</p>

	<p>
	This code was developed within a group of commiters and is licensed under Eclipse Public License (EPL 1.0).
	</p>
	<p>
	<b>Overall design of the code</b>
	<br>
	At top level the project is divided into three packages:
	</p>

	<p>
	<b>backboneCode:</b> This package contains classes that are used to extract and traverse
	the UML models, or store the information about
	which rules that applies to which element for the conformance check and in the end reports it all
	to the user via the Eclipse GUI. The report is prepared by traversing the system model elements
	to see if they deviate from the rules.
	</p>

	<p>
	<b>eArCon.applications:</b> This package contains the main class. It will make use of the other
	classes to do the conformance check.
	</p>

	<p>
	<b>rulePackage:</b> In this package, classes are oriented towards the differnt steps in the conformance check
	of the system model. It's everything from defining the parameters used to specify the rules for
	each UML element to later validating the the system model against the rules from the achitectural model
	</p>

	<h2>Legal Issues</h2>

	<!--
	Please describe any potential legal issues in this section. Does somebody else
	own the trademark to the project name? Is there some issue that prevents you
	from licensing the project under the Eclipse Public License? Are parts of the
	code available under some other license? Are there any LGPL/GPL bits that you
	absolutely require?
	-->
	<p>
	There are no known legal issues.
	</p>

	<h2>Committers</h2>

	<!--
	List any initial committers that should be provisioned along with the
	new project. Include affiliation, but do not include email addresses at
	this point.
	-->

	<p>The following individuals are proposed as initial committers to the project:</p>

	<dl>
	<dt>Gert Johansson, Combitech (lead)</dt>
	<dt>Anders Mattsson, Husqvarna (lead)</dt>
	<dt>Johan Norberg, Combitech</dt>
	<dt>Emil Fridell, Combitech</dt>
	<dt>Carl-Oscar Varnander, Combitech</dt>
	<dt>Leila Azari, Combitech</dt>
	<dt>Rikard Soler Avellen, Combitech</dt>
	</dd>
	</dl>

	<p>We welcome additional committers and contributions.</p>

	<!--
	Describe any initial contributions of code that will be brought to the
	project. If there is no existing code, just remove this section.
	-->

	<h2>Mentors</h2>

	<!--
	New Eclipse projects require a minimum of two mentors from the Architecture
	Council. You need to identify two mentors before the project is created. The
	proposal can be posted before this section is filled in (it's a little easier
	to find a mentor when the proposal itself is public).
	-->

	<p>The following Architecture Council members will mentor this
	project:</p>

	<ul>
	<li>Michael Scharf</li>
	<li>Wayne Beaton</li>
	</ul>

	<h2>Interested Parties</h2>

	<!--
	Provide a list of individuals, organisations, companies, and other Eclipse
	projects that are interested in this project. This list will provide some
	insight into who your project's community will ultimately include. Where
	possible, include affiliations. Do not include email addresses.
	-->

	<p>The following individuals, organisations, companies and projects have
	expressed interest in this project:</p>

	<ul>
	<li>Dominique Toupin, Ericsson</li>
	<li>Ronan Barrett, Ericsson</li>
	<li>Andreas Jakobik, Ericsson</li>
	<li>Patrik Nandorf, Ericsson </li>
	<li>Stefan Grufman, Husqvarna</li>
	<li>Bo Hagerf, Combitech</li>
	<li>Erik Herzog, Saab</li>
	<li>Henrik Andersson, Saab</li>
	<li>Jonas Andersson, Volvo</li>
	<li>Tobias den Braver, Saab EDS</li>
	<li>Björn Lundell, University of Skövde</li>
	<li>Airbus</li>
	</ul>

	<h2>Project Scheduling</h2>

	<!--
	Describe, in rough terms, what the basic scheduling of the project will
	be. You might, for example, include an indication of when an initial contribution
	should be expected, when your first build will be ready, etc. Exact
	dates are not required.
	-->
	<p>
	The ArCon project intends to have a first code contribution ready by June 1st, and
	hopefully the first builds to be ready soon therafter.
	</p>

	<h2>Changes to this Document</h2>

	<!--
	List any changes that have occurred in the document here.
	You only need to document changes that have occurred after the document
	has been posted live for the community to view and comment.
	-->

	<table>
	<tr>
	<th>Date</th>
	<th>Change</th>
	</tr>
	<tr>
	<td>25-February-2013</td>
	<td>Document created</td>
	</tr>
	</table>
	</body>
	</html>