@serverless-devs/s 2.0.96 → 2.0.97-beta.1

package/spec/zh/0.0.1/serverless_package_model/3.package_model.md

@@ -1,434 +0,0 @@
-# Pacakge 模型
-
-Pacakge 模型部分介绍了 Serverless Package Model (SPM) 的建设模型，包括了：
-
-- [模型的组成](#模型的组成)
-- [模型的规范](#模型的规范)
-    - [组件模型规范](#组件模型规范)
-        - [组件模型元数据](#组件模型元数据)
-            - [参数详解](#参数详解)
-                - [Provider](#Provider)
-                - [Category](#Category)
-                - [Service](#Service)
-                - [Properties](#Properties)
-        - [组件模型代码规范](#组件模型代码规范)
-    - [应用模型规范](#应用模型规范)
-        - [应用模型元数据](#应用模型元数据)
-            - [参数详解](#参数详解-1)
-                - [Provider](#Provider-1)
-                - [Category](#Category-1)
-                - [Service](#Service-1)
-
-## 模型的组成
-
-Serverless Package Model 包括两个部分：
-
-- Component Model：组件模型，即通过Serverless Devs，可以被应用所引用，并按照用户的输入，执行预定的功能。例如某个应用中引用了FC组件，那么此时，用户可以通过传入Deploy命令进行函数的部署，而这里的FC组件，则是需要建立在组件模型基础之上，即要符合组件的开发规范；
-- Application Model：应用模型，即通过Serverless Devs，可以被初始化的应用案例，通常一个应用案例包括了一个yaml文件，在该文件中可以包括一个或多个组件来共同完成某个业务。这里所说的应用，就是需要建立在应用模型基础之上的，或者说是需要符合应用开发规范的；
-
-## 模型的规范
-
-### 组件模型规范
-
-Component Model，即组件模型是需要通过指定的文件进行模型的规范和定义的。在这里，推荐的组件模型目录结构为：
-
-```
-|- src # 目录名字可以变更
-|   └── 代码目录  
-|- package.json: 需要定义好main   
-|- publish.yaml: 项目的资源描述   
-|- readme.md: 项目简介  
-|- version.md: 版本更新内容
-```
-
-其中：
-
-| 目录 | 必须 | 含义 |
-| --- | --- | --- |
-| src | 推荐存在 | 统一放置功能实现，当然也可以换成其他的名称，或者平铺到项目下，但是推荐通过src来做统一的存放 |
-| package.json | 必须存在 |  Node.js的package.json，需要描述清楚组件的入口文件位置  |
-| publish.yaml | 必须存在 | Serverless Devs Package的开发识别文档  |
-| readme.md | 必须存在 | 对该组件的描述，或帮助文档信息  |
-| version.md| 推荐存在 | 版本的描述，例如当前版本的更新内容等 |
-
-
-#### 组件模型元数据
-
-组件模型元数据将会在`publish.yaml`中进行描述，并在Serverless Registry和Serverless Devs开发者工具侧进行识别和引用。
-
-`publish.yaml`文件的基本格式如下所示：
-
-```yaml
-Type: Component
-Name: 名称
-Provider:
-  - 云厂商名称 
-Version: 版本，例如0.0.1
-Description: 简短的描述/介绍
-HomePage: 项目首页地址
-Tags: #标签详情
-  - 部署函数
-  - 部署组件
-Category: 分类 # 基础云服务/Web框架/Web应用/人工智能/音视频处理/图文处理/监控告警/大数据/IoT/新手入门/其他
-Service: # 使用的服务
-  - Name: 服务名 # 函数计算/容器服务/镜像服务/消息队列/工作流/CDN/对象存储/表格存储/MNS/日志服务/API网关/数据库/解析服务/云应用/其他
-    # Runtime: Python 3.6 如果服务是函数，还需要增加Runtime
-    Authorities: #权限描述
-      - 创建函数 # 所需要的权限
-Commands: # 指令，格式为指令：指令描述，例如：
-  deploy: 部署函数
-  invoke: 调用函数
-Properties:
-  Region: # 参数
-    Description: 参数描述
-    Required: true # 参数必选，true/false
-    Type: # 参数类型
-      - String
-```
-
-##### 参数详解
-
-| 目录 | 必须 | 结构 | 含义 |
-| --- | --- | --- | --- |
-| Type | 是 | String | 类型，包括Component和Application两个取值，此处取值Component |
-| Name | 是 | String | 组件名称 |
-| Provider | 是 | List<String> | 组件所支持的云厂商信息 |
-| Version | 是 | String | 组件版本号，例如0.0.1 |
-| Description | 是 | String | 组件描述（一句话的简短描述） |
-| HomePage | 否 | String | 组件的主页，可以填写组件的仓库地址 |
-| Tags | 否 | List<String> | 组件的标签 |
-| Category | 是 | String | 组件的分类 |
-| Service | 是 | Struct | 组件所需要的服务和相关的权限等描述，例如该组件需要函数计算，Serverless工作流等产品/服务作为支持 |
-| Commands | 是 | Struct | 组件支持的命令 |
-| Properties | 是 | Struct | 组件的参数描述，组件的属性定义 |
-
-###### Provider
-
-取值范围：`阿里云`, `百度智能云`, `华为云`, `腾讯云`, `AWS`, `Azure`, `Google Cloud`, `其它`
-
-格式参考：
-```yaml
-Provider:
-    - 阿里云
-    - 百度智能云
-```
-
-###### Category
-
-取值范围：`基础云服务`, `Web框架`, `全栈应用`, `人工智能`, `音视频处理`, `图文处理`, `监控告警`, `大数据`, `IoT`, `新手入门`, `其他`
-
-格式参考：
-```yaml
-Category: 基础云服务
-```
-
-###### Service
-
-取值范围：`函数计算`, `容器服务`, `镜像服务`, `消息队列`, `工作流`, `CDN`, `对象存储`, `表格存储`, `MNS`, `日志服务`, `API网关`, `数据库`, `解析服务`, `云应用`, `其他`
-
-格式参考：
-```yaml
-Service: # 使用的服务
-  - Name: 函数计算
-    # Runtime: Python 3.6 如果服务是函数，还需要增加Runtime，取值包括：Node.JS, Python, PHP, Java, Go, 其它
-    Authorities: #权限描述
-      - 创建函数 # 所需要的权限
-```
-
-###### Properties
-
-Properties是对组件的属性进行描述的，所以相对比较负责，主要包括：
-
-| 目录 | 必须 | 结构 | 含义 |
-| --- | --- | --- | --- |
-| Description | 是 | String | 参数描述 |
-| Required | 是 | String | 是否必须 |
-| Type | 是 | Struct | 参数类型 |
-| Example | 否 | String | 参数举例 |
-| Default | 否 | String | 参数默认值 |
-
-关于参数Type(类型)的额外定义：
-
-基本参数类型：`String`, `Number`, `List`, `Enum`, `Struct`, `Boolean`, `Null`, `Any`    
-复杂参数类型：`List<数据类型>`   
-
-另外，当Type是List类型时，可以针对不同的元素做别名：`数据类型[别名]`
-
-格式参考：
-- 简单格式：
-    ```yaml
-    Properties:
-      Region: # 参数
-        Description: 参数描述
-        Required: true # 参数必选，true/false
-        Type: # 参数类型
-          - String
-    ```
-  用户侧表现是：
-   ```yaml
-   Region: cn-hangzhou
-   ```
-- 复杂格式：
-    ```yaml
-    Properties:
-      Region: # 参数
-        Description: 地区
-        Required: true # 参数必选，true/false
-        Type: # 参数类型
-          - String[简单配置]
-          - List<String>[多地域配置]
-          - Struct[分别配置]: 
-              APIGW:
-                Description: API网关部署的地区
-                Required: true 
-                Type: 
-                  - String
-              Function:
-                Description: 函数部署的地区
-                Required: true 
-                Type: 
-                  - String
-    ```
-  用户侧表现是：
-  - 当Type为String[简单配置]时：
-    ```yaml
-    Region: cn-hangzhou
-    ```
-  - 当Type为List<String>[多地域配置]时：
-    ```yaml
-    Region: 
-      - cn-hangzhou
-      - cn-beijing
-    ```
-  - 当Type为Struct[分别配置]时：
-    ```yaml
-    Region: 
-      APIGW: cn-beijing
-      Function: cn-shanghai
-    ```    
-    
-    
-
-#### 组件模型代码规范
-
-在组件模型中，代码组成规范有两个部分：
-- `package.json`中需要描述清楚入口文件所在地址；例如`{"main": "./dist/index.js"}`；
-- 在代码中实现对应的用户方法。例如Package开发者希望用户可以通过deploy命令，进行项目的部署，那么就可以实现一个deploy的方法，并在方法内实现对应的部署能力；
-
-关于代码规范部分，可以参考如下案例：
-
-```typescript
-import logger from './common/logger';
-import { InputProps } from './common/entity';
-
-export default class ComponentDemo {
-  /**
-   * demo 实例
-   * @param inputs
-   * @returns
-   */
-  public async test(inputs: InputProps) {
-    logger.debug(`input: ${JSON.stringify(inputs.props)}`);
-    logger.info('command test');
-    return { hello: 'world' };
-  }
-}
-```
-
-其中入参`inputs`的结构为：
-
-```json
-{
-    "command": "", 
-    "project": {
-        "projectName": "", 
-        "component": "",
-        "provider": "",
-        "access": ""
-    },
-    "credentials": {},
-    "prop": {},
-    "args": "",
-    "argsObj": []
-}
-```
-
-| 目录 | 含义 |
-| --- | --- | 
-| command | 用户所执行的命令 | 
-| project | 用户的项目基本信息 | 
-| credentials | 用户的密钥信息 | 
-| prop | 用户配置的属性/参数 |
-| args| 用户传递的参数（字符串形式） | 
-| argsObj| 用户传递的参数（解析后的，以数组形式传递） |
-
-
-在上面的案例代码中，可以看到有一个test方法，该方法就是功能实现的方法。此时当用户使用test命令时，系统就会携带参数调用该方法。以一个真实案例作为举例说明：
-
-该组件名为`hexo`，组件核心代码如上所示，具备一个test方法，此时用户侧的Yaml为：
-
-```yaml
-edition: 1.0.0        #  命令行YAML规范版本，遵循语义化版本（Semantic Versioning）规范
-name: FullStack       #  项目名称
-access: xxx-account1  #  秘钥别名
-
-services:
-  HexoComponent:
-    component: hexo
-    props:
-      region: 'cn-hangzhou'
-      codeUri: './src'
-```
-
-当用户执行`s test mytest -a -b abc`，此时，组件代码中的`test`方法，收到的`inputs`参数实际上是：
-
-```json
-{
-    "command": "test", 
-    "project": {
-        "projectName": "HexoComponent", 
-        "component": "hexo",
-        "provider": "alibaba",
-        "access": "release"
-    },
-    "credentials": {
-        "AccountID": "********",
-        "AccessKeyID": "********",
-        "AccessKeySecret": "********"
-    },
-    "prop": {
-        "Region": "cn-hangzhou",
-        "CodeUri": "./src"
-    },
-    "args": "mytest -a -b abc",
-    "argsObj": [
-      "mytest", "-a", "-b", "abc"
-    ]
-}
-```
-
-此时test方法会打印日志信息等，并返回最终的结果给命令行工具：`{ "hello": "world" }`
-
-### 应用模型规范
-
-Application Model，即组件模型是需要通过指定的文件进行模型的规范和定义的。在这里，推荐的组件模型目录结构为：
-
-```
-|- src # 目录名字不可以变更
-|   └── 应用目录
-|   └── s.yml: 应用描述文件
-|- publish.yaml: 项目的资源描述   
-|- readme.md: 项目简介  
-|- version.md: 版本更新内容
-```
-
-其中：
-
-| 目录 | 必须 | 含义 |
-| --- | --- | --- |
-| src | 必须存在 | 应用所在目录 |
-| s.yml | 必须存在 | 应用的资源描述Yaml，需要符合该应用对应的publish，yaml规范 |
-| publish.yaml | 必须存在 | Serverless Devs Package的开发识别文档  |
-| readme.md | 必须存在 | 对该组件的描述，或帮助文档信息  |
-| version.md| 推荐存在 | 版本的描述，例如当前版本的更新内容等 |
-
-#### 应用模型元数据
-
-应用模型元数据将会在`publish.yaml`中进行描述，并在Serverless Registry和Serverless Devs开发者工具侧进行识别和初始化。
-
-`publish.yaml`文件的基本格式如下所示：
-
-```yaml
-Type: Application
-Name: 名称
-Provider:
-  - 云厂商名称 
-Version: 版本，例如0.0.1
-Description: 简短的描述/介绍
-HomePage: 项目首页地址
-Tags: #标签详情
-  - 部署函数
-  - 部署组件
-Category: 分类 # 基础云服务/Web框架/Web应用/人工智能/音视频处理/图文处理/监控告警/大数据/IoT/新手入门/其他
-Service: # 使用的服务
-  - Name: 服务名 # 函数计算/容器服务/镜像服务/消息队列/工作流/CDN/对象存储/表格存储/MNS/日志服务/API网关/数据库/解析服务/云应用/其他
-    # Runtime: Python 3.6 如果服务是函数，还需要增加Runtime
-    Authorities: #权限描述
-      - 创建函数 # 所需要的权限
-```
-
-##### 参数详解
-
-| 目录 | 必须 | 结构 | 含义 |
-| --- | --- | --- | --- |
-| Type | 是 | String | 类型，包括Component和Application两个取值，此处取值Application |
-| Name | 是 | String | 组件名称 |
-| Provider | 是 | List<String> | 组件所支持的云厂商信息 |
-| Version | 是 | String | 组件版本号，例如0.0.1 |
-| Description | 是 | String | 组件描述（一句话的简短描述） |
-| HomePage | 否 | String | 组件的主页，可以填写组件的仓库地址 |
-| Tags | 否 | List<String> | 组件的标签 |
-| Category | 是 | String | 组件的分类 |
-| Service | 是 | Struct | 组件所需要的服务和相关的权限等描述，例如该组件需要函数计算，Serverless工作流等产品/服务作为支持 |
-
-
-###### Provider
-
-取值范围：`阿里云`, `百度智能云`, `华为云`, `腾讯云`, `AWS`, `Azure`, `Google Cloud`, `其它`
-
-格式参考：
-```yaml
-Provider:
-    - 阿里云
-    - 百度智能云
-```
-
-###### Category
-
-取值范围：`基础云服务`, `Web框架`, `全栈应用`, `人工智能`, `音视频处理`, `图文处理`, `监控告警`, `大数据`, `IoT`, `新手入门`, `其他`
-
-格式参考：
-```yaml
-Category: 基础云服务
-```
-
-###### Service
-
-取值范围：`函数计算`, `容器服务`, `镜像服务`, `消息队列`, `工作流`, `CDN`, `对象存储`, `表格存储`, `MNS`, `日志服务`, `API网关`, `数据库`, `解析服务`, `云应用`, `其他`
-
-格式参考：
-```yaml
-Service: # 使用的服务
-  - Name: 函数计算
-    # Runtime: Python 3.6 如果服务是函数，还需要增加Runtime，取值包括：Node.JS, Python, PHP, Java, Go, 其它
-    Authorities: #权限描述
-      - 创建函数 # 所需要的权限
-```
-
-> 特殊格式：在应用模型中，需要存在`src/s.yaml`文件，作为Serverless Devs识别和使用的资源、行为描述文件，在该文件中，可能涉及到部分内容是需要用户进行填写的，例如用户的密钥名字，用户部署业务的地域等。此时可以参考：
-> - `"{{ access }}"` ：直接提醒用户需要输入access这样的一个参数，作为Yaml中所必须的参数；
-> - `'{{ bucket | alibaba oss bucket }}'` ： ：直接提醒用户需要输入bucket这样的一个参数，作为Yaml中所必须的参数，并以`|`之后的内容"alibaba oss bucket"作为解释这个参数的含义；
-> 例如，在某应用的`s.yaml`中表现为：
-> ```yaml
-> edition: 1.0.0
-> access: "{{ access }}"
-> 
-> services:
->   website-starter:
->    component: devsapp/website
->     actions:
->       pre-deploy:
->         - run: npm install
->           path: ./
->         - run: npm run build
->           path: ./
->     props:
->       bucket: '{{ bucket | alibaba oss bucket }}'
->       src:
->         codeUri: ./
->         publishDir: ./build
->         index: index.html
->       region: cn-hangzhou
->       hosts:
->         - host: auto
-> ```

package/spec/zh/0.0.1/serverless_package_model/4.application_scopes.md

@@ -1,3 +0,0 @@
-# 适用范围
-
-以上规范适于条件仅限于 Serverless Registry 以及 Serverless Devs 开发者工具 所支持、所识别的文件格式，以及所必须的流程接口。用户/组织可以通过上述的规范可以建立的 Serverless Pacakges 可以直接发布到 Serverless Registry 并被 Serverless Devs 开发者工具 所识别和使用。

package/spec/zh/0.0.1/serverless_package_model/5.design_principles.md

@@ -1,3 +0,0 @@
-# 设计原则
-
-为了给Serverless开发者更简单、更方便、更快速的上手体验，Serverless Devs以开发者为核心，提出了Serverless Package的概念，为了让Serverless Package的开发者，可以更简单、快速的开发出满足Serverless开发者诉求的组件、应用，Serverless Package Model致力于提供更细致化，更规范化的模型基础。

package/spec/zh/0.0.1/serverless_package_model/readme.md

@@ -1,12 +0,0 @@
-# 开发包模型
-
-一个关于 Serverless Package 的规范。Package developer 需要遵循该规范进行组件的开发或者应用的共享，否则将无法被 Serverless Devs 开发者工具 工具所识别和加载，也无法被 Application 所引用，并实现预期的功能。
-
-- [目的和目标](1.purpose_and_goals.md)
-- [概述和术语](2.overview_and_terminology.md)
-  - [Package与Package Model](2.overview_and_terminology.md#package与package-model)
-- [Package 模型](./3.package_model.md)
-  - [模型的组成](./3.registry_model.md#模型的组成)
-  - [模型的规范](./3.registry_model.md#模型的规范)
-- [适用范围](4.application_scopes.md)
-- [设计原则](5.design_principles.md)

package/spec/zh/0.0.1/serverless_registry_model/1.purpose_and_goals.md

@@ -1,18 +0,0 @@
-# 目的和目标
-
-Serverless Registry Model(简称SRM，下文将使用SRM代替)的目标是定义一种 Serverless 架构下的 Registry 的规范，与 Python 中的 pypi， Nodejs 中的 npm 等类似，将以此来开放和分享 Serverless Package，建设 Serverless 生态。
-
-为了让大家更简单的理解 Serverless Registry， 可以通过与 Python Pypi， Nodejs NPM 的对比，进行深入探索：
-
-|  |  **Serverless Reigstry**   | Python Pypi  | Nodejs NPM  |
-|  ----  | ----  | ----  |  ----  |
-| 存储内容  | **Serverless packages**<br>**(包括 Components 和 Application)** | Python packages | Nodejs packages |
-| 是否开放标准  | **是** |  是 |  是 |
-| 官方源 | **registry.devsapp.cn/simple** | pypi.python.org | registry.npmjs.org |
-| 其它源举例 | **Github registry** <br> **Gitee registry** | 清华源 <br> 豆瓣源 | tnpm <br> cnpm |
-| 是否支持私有化 | **支持** | 支持 | 支持 |
-| 配套工具 | **Serverless Devs 开发者工具** | Python包管理工具(pip) | Node.js打包管理工具(npm) |
-| 配套命令 | **s** | pip | npm |
-| 如何使用 | 在`s.yaml`中直接引用 | 安装之后，在代码中引用 | 安装之后，在代码中引用 |
-
-本规范，提供了对 Serverless 应用开发和部署的相关生态的支持，通过本规范可以快速的创建公开的/私有化的 Serverless Registry，并通过 Serverless Devs 开发者工具 进行使用，助力 Serverless 应用开发者可以更简单，更快速，更方便的使用不同平台的 Serverless 产品，可以提升功能效能。

package/spec/zh/0.0.1/serverless_registry_model/2.overview_and_terminology.md

@@ -1,18 +0,0 @@
-# 概述和术语
-
-本节讲述了 SRM 及其术语。它首先是一个 Serverless Devs Model(SDM) 中不可或缺的概念，它代表的是 Serverless 的一种开发者生态，Serverless Devs 开发者工具 开发者工具将会通过 Serverless Registry 进行应用案例的拉取，或者组件的下载和使用，而 Serverless Registry Model(SRM) 则是 Serverless Registry 的规范和标准。
-
-## 模型概述
-
-该规范提出了一个模型，定义 Serverless Registry 如下：
-
-> Serverless Registry 是承载 Serverless 生态的抽象概念，与 Python Pypi，Nodejs NPM 等类似，Serverless Registry 用于开放和共享 Serverless Package。
-
-在当前版本中，Serverless Registry 定义了以下内容：
-- Serverless Registry 将会同时承载应用和组件；
-- 应用和组件在 Serverless Registry 上将会具有不同数据结构的元数据；
-- Serverless Registry 的应用可以通过规范的 API 进行查询和获取；
-- Serverless Registry 可以且仅可以承载符合 [Serverless Package Model 规范](./../serverless_package_model)的 Package （包括应用与组件）；
-- Serverless Registry 所承载的内容可以在之后的版本进行拓展；
-- Serverless Registry 可以根据 Registry 建设者/组织的需求增加符合自身需要的权限鉴定策略；
-- Serverless Registry 中的 Package （包括应用与组件）应当具备版本的划分能力，以及 Package 的增加、删除的能力；

package/spec/zh/0.0.1/serverless_registry_model/3.registry_model.md

@@ -1,61 +0,0 @@
-# Registry 模型
-
-Registry 模型部分介绍了 Serverless Registry Model (SRM) 的建设模型，包括了：
-
-- [元数据规范](#元数据规范)
-- [Registry 规范](#registry规范)
-
-## 元数据规范
-
-Serverless Reigstry 需要获得并存储 Package 以下信息：
-
-| 数据名 |  类型   | 描述  |
-|  ----  | ----  | ----  |
-| Name  | String | Package名称 |
-| Type  | String | Component/Application |
-| Version  | String | Package版本，需要符合`主版本号.子版本号.修正版本号`格式 |
-| PublishTime  | Number | 发布时间戳（秒） |
-| VersionBody  | String | 版本对应的描述 |
-
-> 除了以上基础规范，Serverless Registry 的提供者/组织还可以根据具体需求，存储更多的数据/信息，包括不限于用于鉴权使用的 Package 贡献者id，用户确定 Package 状态的status等；
-
-## Registry 规范
-
-Package 开发者和 Serverless 开发者在发布 Package 以及使用 Package 的流程可以简化为：
-
-![](https://serverless-article-picture.oss-cn-hangzhou.aliyuncs.com/1631783208215_20210916090651949970.png)
-
-通过上述流程，可以看到对于 Package 开发者而言，需要按照[Serverless Package Model 规范](./../serverless_package_model)提供相对应的 Package 到 Serverless Registry，而对于 Serverless 开发者而言，则需通过 Serverless Devs 开发者工具 工具中，进行 Package 的下载和使用。在整个过程中，涉及到的核心规范如下：
-
-- Serverless Registry 在接受 Package 开发者贡献的组件与应用时，接受且只接受标准zip格式的压缩包，且压缩包中包括的代码等内容符合且必须符合符合 [Serverless Package Model 规范](./../serverless_package_model)；
-- 对于发布在 Serverless Registry 上的应用和组件，Serverless Registry 需要按照以下规范提供对应 Package 版本查询功能以及相对应的下载功能：
-    - 全部版本查询：
-        - Method：GET
-        - URI：{package-name}/releases/latest
-        - Response：
-            ```
-            {
-                "tag_name": "1.1.13",
-                "created_at": "2021-01-04T07:41:23Z",
-                "zipball_url": "https://api.github.com/repos/Serverless-Devs/Serverless-Devs/zipball/1.1.13",
-                "body": "- 中文\r\n  - 修复边界条件下临时密钥获取失败的BUG\r\n- English: \r\n  - Fix the bug that the temporary key acquisition fails under boundary conditions"
-            }
-            ```
-    - 最新版本查询：
-        - Method：GET
-        - URI：{package-name}/releases/latest
-        - Response：
-            ```
-            {
-                "tag_name": "1.1.13",
-                "created_at": "2021-01-04T07:41:23Z",
-                "zipball_url": "https://api.github.com/repos/Serverless-Devs/Serverless-Devs/zipball/1.1.13",
-                "body": "- 中文\r\n  - 修复边界条件下临时密钥获取失败的BUG\r\n- English: \r\n  - Fix the bug that the temporary key acquisition fails under boundary conditions"
-            }
-            ```
-    - Package下载：
-        - Method：GET
-        - URI：{package-name}/zipball/{version}
-        - Response：组件压缩包
-
-> 除了以上基础规范，Serverless Registry 的提供者/组织还可以根据具体需求，提供 Package 更新，删除以及权限变更等相关的额外能力。

package/spec/zh/0.0.1/serverless_registry_model/4.application_scopes.md

@@ -1,6 +0,0 @@
-# 适用范围
-
-以上规范适于条件仅限于 Serverless Devs 开发者工具 所支持、所识别的文件格式，以及所必须的流程接口。用户/组织可以通过上述的规范可以建立的 Serverless Registry 可以直接被 Serverless Devs 开发者工具 所识别和使用。
-
-但是并不代表 Serverless Registry 的功能仅如此，作为 Serverless Registry 的建设者和维护者，有权在保证符合上述规范的前提下丰富相对应的接口以及能力。包括不限于所春初的元数据的丰富，所支持的接口能力的丰富等，这些额外的能力将作为 Serverless Registry 的拓展能力存在，并不作为 Serverless Registry Model的一部分。
- 

package/spec/zh/0.0.1/serverless_registry_model/5.design_principles.md

@@ -1,3 +0,0 @@
-# 设计原则
-
-为了更加公平和开放，上述的设计规范参照于Github相关接口设计，所以可以认为 Serverless Devs 开发者工具 天然支持 Github 作为其默认的 Serverless Registry ( https://api.github.com/repos/ )。

package/spec/zh/0.0.1/serverless_registry_model/readme.md

@@ -1,12 +0,0 @@
-# Registry模型
-
-一个开放的 Serverless Registry Model。Package的开发者可以将自己开发的组件，或者待分享的应用发布到该平台。该平台可以使用目前 Serverless Devs 所支持的 Github Resitry， Gitee Registry， Serverless Registry，也可以按照该规范搭建私有的 Registry 以完成部分能力。
-
-- [目的和目标](1.purpose_and_goals.md)
-- [概述和术语](2.overview_and_terminology.md)
-  - [模型概述](2.overview_and_terminology.md#模型概述)
-- [Registry 模型](3.registry_model.md)
-  - [元数据规范](3.registry_model.md#元数据规范)
-  - [Registry 规范](3.registry_model.md#registry-规范)
-- [适用范围](4.application_scopes.md)
-- [设计原则](5.design_principles.md)

package/spec/zh/0.0.1/serverless_user_model/1.purpose_and_goals.md

@@ -1,3 +0,0 @@
-# 目的和目标
-
-Serverless User Model(简称SUM，下文将使用SUM代替)的目标是定义一种 Serverless 开发者模型以及开发者规范；核心目的是基于这套模型或者规范所开发的项目，开发者可以更简单，更方便，更快速的开发Serverless应用，并将其部署到线上，并且可以在应用全生命周期发挥作用。

package/spec/zh/0.0.1/serverless_user_model/2.overview_and_terminology.md

@@ -1,16 +0,0 @@
-# 概述和术语
-
-Serverless User Model(SUM) 是针对 Serverless 开发者的应用模型，也是Serverless应用开发者的开发规范，通过该规范开发的应用，可以被Serverless Devs开发者工具所识别，并使用Serverless Registry所提供的组件进行相关功能的实现。
-
-![](https://serverless-article-picture.oss-cn-hangzhou.aliyuncs.com/1631934027954_20210918030028156081.png)
-
-
-### 模型概述
-
-该规范提出了一个Serverless开发者模型，定义 Serverless Application 规范如下：
-
-> Serverless 应用指的是可以被Serverless Devs开发者工具所识别的Serverless应用，需要具备一个符合Serverless Application 的 Yaml 文件，对应用进行相对应的资源描述与行为描述。
-
-在当前版本中，Serverless User Model 定义了以下内容：
-- Serverless Application 规范
-- Serverless Package Component 使用规范