Spellcheck
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/examples/use_case_spec.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/examples/use_case_spec.xmi
index 50b8988..de96fff 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/examples/use_case_spec.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/examples/use_case_spec.xmi
@@ -201,7 +201,7 @@
</p>
<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
<p>
- 1. The ATM shall print a receipt indicating the transaction was cancelled.
+ 1. The ATM shall print a receipt indicating the transaction was canceled.
</p>
<p>
2. The ATM shall return the card.
diff --git a/epf_prac_151/practice.bus.mdev.base/guidances/guidelines/defining_method_elements.xmi b/epf_prac_151/practice.bus.mdev.base/guidances/guidelines/defining_method_elements.xmi
index 8099ca5..9ddf710 100644
--- a/epf_prac_151/practice.bus.mdev.base/guidances/guidelines/defining_method_elements.xmi
+++ b/epf_prac_151/practice.bus.mdev.base/guidances/guidelines/defining_method_elements.xmi
@@ -802,7 +802,7 @@
</li>
<li>
Package specific tasks in your context. For tasks that are likely to need to be ‘split' later, package them in
- their own pkg.
+ their own package.
</li>
</ul>
<h5>
diff --git a/epf_prac_151/practice.bus.mdev.base/guidances/guidelines/testing_a_method_asset.xmi b/epf_prac_151/practice.bus.mdev.base/guidances/guidelines/testing_a_method_asset.xmi
index 4f62ac1..3599d08 100644
--- a/epf_prac_151/practice.bus.mdev.base/guidances/guidelines/testing_a_method_asset.xmi
+++ b/epf_prac_151/practice.bus.mdev.base/guidances/guidelines/testing_a_method_asset.xmi
@@ -289,7 +289,7 @@
company copyright), and confirm it publishes correctly.
</p>
<p>
- Confirm that licencing/legal information is attached and publishes.
+ Confirm that licensing/legal information is attached and publishes.
</p>
<h4>
Accessibility
diff --git a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/concepts/project_lifecycle.xmi b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/concepts/project_lifecycle.xmi
index 7a36266..91e0ea5 100644
--- a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/concepts/project_lifecycle.xmi
+++ b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/concepts/project_lifecycle.xmi
@@ -56,7 +56,7 @@
<p>
If the answer is Yes to those questions at the phase review, the project continues. If the answer is No, the phase is
delayed (usually by adding an extra iteration) until a satisfactory answer is received, or the stakeholders may
- determine that the project should be cancelled.
+ determine that the project should be canceled.
</p>
<p>
Within each phase, you might have one or several iterations, where the iterations aim at producing the results required
diff --git a/epf_prac_151/practice.tech.abrd.base/guidances/concepts/cycle_approach.xmi b/epf_prac_151/practice.tech.abrd.base/guidances/concepts/cycle_approach.xmi
index da22122..1b7547b 100644
--- a/epf_prac_151/practice.tech.abrd.base/guidances/concepts/cycle_approach.xmi
+++ b/epf_prac_151/practice.tech.abrd.base/guidances/concepts/cycle_approach.xmi
@@ -262,7 +262,7 @@
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'; mso-bidi-language: AR-SA; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-font-family: 'Times New Roman'; mso-bidi-font-size: 12.0pt">The
goal of this cycle is to deploy the rule set under construction to the execution server in order to test it with an
end-to-end scenario. The integration of the decision service and the&nbsp;domain object model is an important task.
- Integration involves the marshalling of data to/from external data sources, such as Database, MOM, files or sockets
+ Integration involves the marshaling of data to/from external data sources, such as Database, MOM, files or sockets
into a form that can be understood by the execution engine. This is a 'mapping' of the data received by the decision
service to the Business Object Model created in previous activities.<br />
There are a number of tools and techniques that can be used to marshal data, and the best choice will vary by project.
diff --git a/epf_prac_151/practice.tech.abrd.base/guidances/supportingmaterials/introduction.xmi b/epf_prac_151/practice.tech.abrd.base/guidances/supportingmaterials/introduction.xmi
index e85edcc..de69872 100644
--- a/epf_prac_151/practice.tech.abrd.base/guidances/supportingmaterials/introduction.xmi
+++ b/epf_prac_151/practice.tech.abrd.base/guidances/supportingmaterials/introduction.xmi
@@ -184,7 +184,7 @@
<span style="FONT-FAMILY: Symbol; mso-fareast-font-family: Symbol; mso-bidi-font-family: Symbol"><span
style="mso-list: Ignore">·</span></span> <i>Customer collaboration over contract negotiation</i>. Subject Matter
Experts who define the business policies and the business rules are strongly involved in the development process. They
- are the customers of the final system, owners of the policies and are conveniently collocated with the development team
+ are the customers of the final system, owners of the policies and are conveniently colocated with the development team
during the project.
</p>
<p style="TEXT-INDENT: -0.25in; MARGIN: 3pt 0in 3pt 36.3pt; tab-stops: list 36.3pt; mso-list: l0 level1 lfo1"
diff --git a/epf_prac_151/practice.tech.abrd.base/tasks/define_discovery_roadmap.xmi b/epf_prac_151/practice.tech.abrd.base/tasks/define_discovery_roadmap.xmi
index 9ff6bd3..d34e920 100644
--- a/epf_prac_151/practice.tech.abrd.base/tasks/define_discovery_roadmap.xmi
+++ b/epf_prac_151/practice.tech.abrd.base/tasks/define_discovery_roadmap.xmi
@@ -1,14 +1,14 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:TaskDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-Ak_E6i3qbz4NMG7ynyf4DA" name="define_discovery_roadmap,_srklxgjqEdyj5bYZ0eCR5g" guid="-Ak_E6i3qbz4NMG7ynyf4DA" authors="Jerome Boyer" changeDate="2008-09-05T10:15:16.000-0700" version="1.0.0">
<mainDescription><p>
- There are two dimensions to consider when preparing the rule discovery activi-ties or roadmap:
+ There are two dimensions to consider when preparing the rule discovery activities or roadmap:
</p>
<ul>
<li>
The type of source for rule harvesting
</li>
<li>
- The type of analysis used by the project team: use case approach, busi-ness process modeling, mission policies
+ The type of analysis used by the project team: use case approach, business process modeling, mission policies
analysis
</li>
</ul>
diff --git a/epf_prac_151/practice.tech.abrd.base/tasks/execute_rule_discovery_roadmap.xmi b/epf_prac_151/practice.tech.abrd.base/tasks/execute_rule_discovery_roadmap.xmi
index 1aefd9b..b17a9f5 100644
--- a/epf_prac_151/practice.tech.abrd.base/tasks/execute_rule_discovery_roadmap.xmi
+++ b/epf_prac_151/practice.tech.abrd.base/tasks/execute_rule_discovery_roadmap.xmi
@@ -8,7 +8,7 @@
The documentation of the rule may be done using different language. The natural language is initially used during
business conversations to describe the rule, informally, without trying to impose any structure. SMEs express their
ideas using a language very close to them, but they usually are not able to formalize their concepts in a clear and
- unambiguous way. Using this language we may have redundancy and inconstancy in the rule ex-pression, in the business
+ unambiguous way. Using this language we may have redundancy and inconstancy in the rule expression, in the business
terms, and overall by it may not be relevant and precise enough to be able to implement the decision logic.
</p>
<p>
diff --git a/epf_prac_151/process.abrd.base/capabilitypatterns/discover_business_rules/content.xmi b/epf_prac_151/process.abrd.base/capabilitypatterns/discover_business_rules/content.xmi
index 5aa7232..327182f 100644
--- a/epf_prac_151/process.abrd.base/capabilitypatterns/discover_business_rules/content.xmi
+++ b/epf_prac_151/process.abrd.base/capabilitypatterns/discover_business_rules/content.xmi
@@ -218,14 +218,14 @@
</org.eclipse.epf.uma:DescriptorDescription>
<org.eclipse.epf.uma:DescriptorDescription xmi:id="-Zt7Ibx5DM49KKxndcqRTtw" name="define_discovery_roadmap,_JbeFsHt0Ed2obd5av1OT7w" guid="-Zt7Ibx5DM49KKxndcqRTtw">
<refinedDescription><p>
- There are two dimensions to consider when preparing the rule discovery activi-ties or roadmap:
+ There are two dimensions to consider when preparing the rule discovery activities or roadmap:
</p>
<ul>
<li>
The type of source for rule harvesting
</li>
<li>
- The type of analysis used by the project team: use case approach, busi-ness process modeling, mission policies
+ The type of analysis used by the project team: use case approach, business process modeling, mission policies
analysis
</li>
</ul>
@@ -478,7 +478,7 @@
The documentation of the rule may be done using different language. The natural language is initially used during
business conversations to describe the rule, informally, without trying to impose any structure. SMEs express their
ideas using a language very close to them, but they usually are not able to formalize their concepts in a clear and
- unambiguous way. Using this language we may have redundancy and inconstancy in the rule ex-pression, in the business
+ unambiguous way. Using this language we may have redundancy and inconstancy in the rule expression, in the business
terms, and overall by it may not be relevant and precise enough to be able to implement the decision logic.
</p>
<p>
diff --git a/epf_prac_151/process.abrd.base/deliveryprocesses/abrd_process/content.xmi b/epf_prac_151/process.abrd.base/deliveryprocesses/abrd_process/content.xmi
index f27db24..ee3b4ed 100644
--- a/epf_prac_151/process.abrd.base/deliveryprocesses/abrd_process/content.xmi
+++ b/epf_prac_151/process.abrd.base/deliveryprocesses/abrd_process/content.xmi
@@ -240,14 +240,14 @@
</org.eclipse.epf.uma:DescriptorDescription>
<org.eclipse.epf.uma:DescriptorDescription xmi:id="-SZIhc8oXvpac5M1fKbXgTA" name="define_discovery_roadmap,_nIvp3MVVEd2pfdXgw7I2qQ" guid="-SZIhc8oXvpac5M1fKbXgTA">
<refinedDescription><p>
- There are two dimensions to consider when preparing the rule discovery activi-ties or roadmap:
+ There are two dimensions to consider when preparing the rule discovery activities or roadmap:
</p>
<ul>
<li>
The type of source for rule harvesting
</li>
<li>
- The type of analysis used by the project team: use case approach, busi-ness process modeling, mission policies
+ The type of analysis used by the project team: use case approach, business process modeling, mission policies
analysis
</li>
</ul>
@@ -500,7 +500,7 @@
The documentation of the rule may be done using different language. The natural language is initially used during
business conversations to describe the rule, informally, without trying to impose any structure. SMEs express their
ideas using a language very close to them, but they usually are not able to formalize their concepts in a clear and
- unambiguous way. Using this language we may have redundancy and inconstancy in the rule ex-pression, in the business
+ unambiguous way. Using this language we may have redundancy and inconstancy in the rule expression, in the business
terms, and overall by it may not be relevant and precise enough to be able to implement the decision logic.
</p>
<p>
@@ -1387,7 +1387,7 @@
The documentation of the rule may be done using different language. The natural language is initially used during
business conversations to describe the rule, informally, without trying to impose any structure. SMEs express their
ideas using a language very close to them, but they usually are not able to formalize their concepts in a clear and
- unambiguous way. Using this language we may have redundancy and inconstancy in the rule ex-pression, in the business
+ unambiguous way. Using this language we may have redundancy and inconstancy in the rule expression, in the business
terms, and overall by it may not be relevant and precise enough to be able to implement the decision logic.
</p>
<p>
@@ -3982,7 +3982,7 @@
The documentation of the rule may be done using different language. The natural language is initially used during
business conversations to describe the rule, informally, without trying to impose any structure. SMEs express their
ideas using a language very close to them, but they usually are not able to formalize their concepts in a clear and
- unambiguous way. Using this language we may have redundancy and inconstancy in the rule ex-pression, in the business
+ unambiguous way. Using this language we may have redundancy and inconstancy in the rule expression, in the business
terms, and overall by it may not be relevant and precise enough to be able to implement the decision logic.
</p>
<p>
@@ -6094,7 +6094,7 @@
The documentation of the rule may be done using different language. The natural language is initially used during
business conversations to describe the rule, informally, without trying to impose any structure. SMEs express their
ideas using a language very close to them, but they usually are not able to formalize their concepts in a clear and
- unambiguous way. Using this language we may have redundancy and inconstancy in the rule ex-pression, in the business
+ unambiguous way. Using this language we may have redundancy and inconstancy in the rule expression, in the business
terms, and overall by it may not be relevant and precise enough to be able to implement the decision logic.
</p>
<p>
diff --git a/epf_prac_151/process.abrd.base/deliveryprocesses/openUp_abrd/content.xmi b/epf_prac_151/process.abrd.base/deliveryprocesses/openUp_abrd/content.xmi
index 7860471..4acd015 100644
--- a/epf_prac_151/process.abrd.base/deliveryprocesses/openUp_abrd/content.xmi
+++ b/epf_prac_151/process.abrd.base/deliveryprocesses/openUp_abrd/content.xmi
@@ -47,14 +47,14 @@
</org.eclipse.epf.uma:DescriptorDescription>
<org.eclipse.epf.uma:DescriptorDescription xmi:id="-dZH2mwKP_HVhAcRXF625-g" name="define_discovery_roadmap,_dS7G4D3hEd-rQL4FfV6WbQ" guid="-dZH2mwKP_HVhAcRXF625-g">
<refinedDescription><p>
- There are two dimensions to consider when preparing the rule discovery activi-ties or roadmap:
+ There are two dimensions to consider when preparing the rule discovery activities or roadmap:
</p>
<ul>
<li>
The type of source for rule harvesting
</li>
<li>
- The type of analysis used by the project team: use case approach, busi-ness process modeling, mission policies
+ The type of analysis used by the project team: use case approach, business process modeling, mission policies
analysis
</li>
</ul>
@@ -120,7 +120,7 @@
The documentation of the rule may be done using different language. The natural language is initially used during
business conversations to describe the rule, informally, without trying to impose any structure. SMEs express their
ideas using a language very close to them, but they usually are not able to formalize their concepts in a clear and
- unambiguous way. Using this language we may have redundancy and inconstancy in the rule ex-pression, in the business
+ unambiguous way. Using this language we may have redundancy and inconstancy in the rule expression, in the business
terms, and overall by it may not be relevant and precise enough to be able to implement the decision logic.
</p>
<p>
@@ -933,7 +933,7 @@
The documentation of the rule may be done using different language. The natural language is initially used during
business conversations to describe the rule, informally, without trying to impose any structure. SMEs express their
ideas using a language very close to them, but they usually are not able to formalize their concepts in a clear and
- unambiguous way. Using this language we may have redundancy and inconstancy in the rule ex-pression, in the business
+ unambiguous way. Using this language we may have redundancy and inconstancy in the rule expression, in the business
terms, and overall by it may not be relevant and precise enough to be able to implement the decision logic.
</p>
<p>
@@ -2600,7 +2600,7 @@
The documentation of the rule may be done using different language. The natural language is initially used during
business conversations to describe the rule, informally, without trying to impose any structure. SMEs express their
ideas using a language very close to them, but they usually are not able to formalize their concepts in a clear and
- unambiguous way. Using this language we may have redundancy and inconstancy in the rule ex-pression, in the business
+ unambiguous way. Using this language we may have redundancy and inconstancy in the rule expression, in the business
terms, and overall by it may not be relevant and precise enough to be able to implement the decision logic.
</p>
<p>
@@ -3266,7 +3266,7 @@
The documentation of the rule may be done using different language. The natural language is initially used during
business conversations to describe the rule, informally, without trying to impose any structure. SMEs express their
ideas using a language very close to them, but they usually are not able to formalize their concepts in a clear and
- unambiguous way. Using this language we may have redundancy and inconstancy in the rule ex-pression, in the business
+ unambiguous way. Using this language we may have redundancy and inconstancy in the rule expression, in the business
terms, and overall by it may not be relevant and precise enough to be able to implement the decision logic.
</p>
<p>
diff --git a/epf_prac_151/publish.openup.base/guidances/concepts/core_principle_balance.xmi b/epf_prac_151/publish.openup.base/guidances/concepts/core_principle_balance.xmi
index b94b559..32c315b 100644
--- a/epf_prac_151/publish.openup.base/guidances/concepts/core_principle_balance.xmi
+++ b/epf_prac_151/publish.openup.base/guidances/concepts/core_principle_balance.xmi
@@ -1,5 +1,5 @@
<?xml version="1.0" encoding="UTF-8"?>
-<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-I4IbR1GW6IFBCdq9SiMUsw" name="core_principle_balance,_ssG6MMvpEdqukPpotm3DYg" guid="-I4IbR1GW6IFBCdq9SiMUsw" changeDate="2008-01-23T05:11:19.000-0800" changeDescription="Removed metaphoric photo Removed open_up from page name." version="0.02">
+<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-I4IbR1GW6IFBCdq9SiMUsw" name="core_principle_balance,_ssG6MMvpEdqukPpotm3DYg" guid="-I4IbR1GW6IFBCdq9SiMUsw" changeDate="2008-01-23T05:11:19.000-0800" changeDescription="Removed metaphorical photo Removed open_up from page name." version="0.02">
<mainDescription><h3>
Introduction
</h3>
diff --git a/epf_prac_151/publish.openup.base/guidances/concepts/core_principle_collaborate.xmi b/epf_prac_151/publish.openup.base/guidances/concepts/core_principle_collaborate.xmi
index 22e571d..63e5685 100644
--- a/epf_prac_151/publish.openup.base/guidances/concepts/core_principle_collaborate.xmi
+++ b/epf_prac_151/publish.openup.base/guidances/concepts/core_principle_collaborate.xmi
@@ -1,5 +1,5 @@
<?xml version="1.0" encoding="UTF-8"?>
-<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-IXfkG-XfnoEo0xgux482Kw" name="core_principle_collaborate,_KkTIsMp7EdqC_NfSivunjA" guid="-IXfkG-XfnoEo0xgux482Kw" authors="Steve Adolph" changeDate="2008-01-23T05:13:21.000-0800" changeDescription="Initial Version |Removed metaphoric photo. Removed "Don't go dark" collaborative practice.|Removed metaphoric photo. Removed "Don't go dark" collaborative practice. Removed open_up from page name.|Added "organize around the architecture practice"" version="0.03">
+<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-IXfkG-XfnoEo0xgux482Kw" name="core_principle_collaborate,_KkTIsMp7EdqC_NfSivunjA" guid="-IXfkG-XfnoEo0xgux482Kw" authors="Steve Adolph" changeDate="2008-01-23T05:13:21.000-0800" changeDescription="Initial Version |Removed metaphorical photo. Removed "Don't go dark" collaborative practice.|Removed metaphorical photo. Removed "Don't go dark" collaborative practice. Removed open_up from page name.|Added "organize around the architecture practice"" version="0.03">
<mainDescription><h3>
Introduction
</h3>
diff --git a/epf_prac_151/publish.openup.base/guidances/roadmaps/openup_roadmap.xmi b/epf_prac_151/publish.openup.base/guidances/roadmaps/openup_roadmap.xmi
index 916ba27..e4dc7ba 100644
--- a/epf_prac_151/publish.openup.base/guidances/roadmaps/openup_roadmap.xmi
+++ b/epf_prac_151/publish.openup.base/guidances/roadmaps/openup_roadmap.xmi
@@ -44,7 +44,7 @@
</p>
<p>
OpenUP does not include content for deployment, configuration management, or the development environment (such as
- customizing this process or setting up development environments). OpenUP focuses on a singe team, and these areas are
+ customizing this process or setting up development environments). OpenUP focuses on a single team, and these areas are
generally addressed at an organizational or enterprise level. Look for extensions to OpenUP that address these wider
areas.
</p>
