Merge pull request #453 from resouer/dev

Fix typo in v0.3.0

3.component_model.md

@@ -2,7 +2,7 @@
 
 This section defines component model.
 
-Components describe functional units that may be instantiated as part of a larger distributed application. The [`Application`](7.application_configuration.md) will describe how components are grouped together and how instances of those components are then configured, while this section will focus on component model.
+Components describe functional units that may be instantiated as part of a larger distributed application. The [`Application`](7.application_configuration.md) section will describe how components are grouped together and how instances of those components are then configured, while this section will focus on component model itself.
 
 ![alt](./assets/modern_app.png)
 

4.workload_types.md

@@ -2,7 +2,7 @@
 
 Using workload type is covered in component model section, but workload type definitions are described here.
 
-Workload types are provided by the platform so that users may inspect the platform and learn what workload types are available for use in a component definition. Note that workload types are not extensible to end users (only to platform operators). Thus, end users MUST NOT be allowed to create new workload types.
+Workload type is the key characteristic of a given component definition. Workload types are provided by the platform so that users may inspect the platform and learn what workload types are available for use. Note that workload types are not extensible to end users (only to platform operators). Thus, end users MUST NOT be allowed to create new workload types.
 
 ## Representation
 
@@ -105,18 +105,21 @@ spec:
 
 ## The Relationship of Component and Workload Type
 
-In nutshell, the `ComponentDefinition` is the user provided encapsulation for `WorkloadDefinition` available in the platform. Below examples may help to explain their relationships better:
+In nutshell, a component is a user maintained **encapsulation** for certain platform capabilities and workload type is the key one of them. That's also why a component is required to explicitly declare the workload type in its definition: the trait system need to know this to decide whether a certain trait can be attached to this component.
 
-- A `Web Service` component that encapsulates a Kubernetes Deployment with a Service resource.
+Below examples may also help to explain their relationships better:
+
+- A `Web Service` component that encapsulates a Kubernetes Deployment + a Service.
   - The `apps/v1.Deployment` is the workload type for this component in this case.
-- A `Backend Worker` component that only encapsulates a Kubernetes Deployment resource.
+- A `Backend Worker` component that encapsulates a Kubernetes Deployment.
   - The `apps/v1.Deployment` is still the workload type for this component in this case.
-- A Helm chart is a component, the `apps/v1.Deployment` is the workload type for this component.
-- `ComponentDefinition` is defined by component provider, `WorkloadDefinition` is defined by infrastructure operator.
-  - Hence a platform normally has unlimited number of component definitions but limited number of workload definitions present.
+- A Helm chart which templates a Kubernetes Deployment + a Ingress is also a component.
+  - The `apps/v1.Deployment` is the workload type for this component.
 
 ![alt](./assets/concepts.png)
 
+From another angle, the `ComponentDefinition` is always defined by platform user (normally, component provider or software builder), while a `WorkloadDefinition`, as a platform capability, is always maintained by infrastructure operator. Hence, a OAM platform normally has very limited number of workload definitions and they do not change a lot, but always have countless component definitions maintained by different users.
+
 | Previous      | Next        |
 | ------------- |-------------|
 [3. The Component Model](3.component_model.md) | [5. Application Scopes](5.application_scopes.md)|

5.application_scopes.md

@@ -64,7 +64,7 @@ spec:
     name: healthscopes.core.oam.dev
 ```
 
-The following scope capabilities are defined in the OAM specification.
+The following sample scope capabilities are defined in the OAM specification.
 
 ### Health Scope
 

7.application_configuration.md

@@ -173,7 +173,7 @@ The releases can also be named as `Snapshot` according to the implementations, i
 
 ## Further Reading
 
-For further details about deploy an application, see this [example workflow](examples/workflow.md).
+For further details about a full workflow of application deployment, please check [KubeVela's documentation](https://kubevela.io/docs/application).
 
 | Tables        | Next           |
 | ------------- |-------------|

SPEC.md

@@ -12,8 +12,8 @@ Learn more about versioning [below](#versioning).
 
   1. [Purpose and Goals](1.purpose_and_goals.md)
   1. [Overview and Terminology](2.overview_and_terminology.md)
-  1. [Component Model](3.component.md)
-  1. [Workload Type](4.workload_types.md)
+  1. [Component Model](3.component_model.md)
+  1. [Workload Types](4.workload_types.md)
   1. [Application Scopes](5.application_scopes.md)
   1. [Traits](6.traits.md)
   1. [Application](7.application_configuration.md)
@@ -27,7 +27,7 @@ Learn more about versioning [below](#versioning).
 | ComponentDefiniton | core | v1beta1 |
 | WorkloadDefiniton | core | v1beta1 |
 | TraitDefinition | core | v1beta1 |
-| Application Scope | core | v1alpha2 |
+| Application Scope | core | v1beta1 |
 | Application  | core | v1beta1   |
 
 ## Versioning