remove components docs
redirect to taverna-extras
git-svn-id: https://svn.apache.org/repos/asf/incubator/taverna/site/trunk@1834676 13f79535-47bb-0310-9956-ffa450edef68
diff --git a/content/documentation/components/.htaccess b/content/documentation/components/.htaccess
new file mode 100644
index 0000000..92d6100
--- /dev/null
+++ b/content/documentation/components/.htaccess
@@ -0,0 +1,7 @@
+RewriteEngine On
+
+RewriteRule index.html https://github.com/taverna-extras/taverna-plugin-component/tree/master/doc [L,R]
+RewriteRule ^$ https://github.com/taverna-extras/taverna-plugin-component/tree/master/doc [L,R]
+RewriteRule component-profile-editor.* https://github.com/taverna-extras/taverna-plugin-component/blob/master/doc/component-profile-editor.md [L,R]
+RewriteRule component-validator.* https://github.com/taverna-extras/taverna-plugin-component/blob/master/doc/component-validator.md [L,R]
+RewriteRule .* https://github.com/taverna-extras/taverna-plugin-component/ [L,R]
diff --git a/content/documentation/components/component-profile-editor.md b/content/documentation/components/component-profile-editor.md
deleted file mode 100644
index 7cfda58..0000000
--- a/content/documentation/components/component-profile-editor.md
+++ /dev/null
@@ -1,26 +0,0 @@
-Title: Component profile editor
-Notice: Licensed to the Apache Software Foundation (ASF) under one
- or more contributor license agreements. See the NOTICE file
- distributed with this work for additional information
- regarding copyright ownership. The ASF licenses this file
- to you under the Apache License, Version 2.0 (the
- "License"); you may not use this file except in compliance
- with the License. You may obtain a copy of the License at
- .
- http://www.apache.org/licenses/LICENSE-2.0
- .
- Unless required by applicable law or agreed to in writing,
- software distributed under the License is distributed on an
- "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- KIND, either express or implied. See the License for the
- specific language governing permissions and limitations
- under the License.
-
-The Taverna Component Profile Editor is a simple tool for editing and creating profiles for
- [Taverna Components[(/documentation/components).
-Component profiles define the required and supported interface of components;
- they are not intended to be easily edited by normal users.
-The editor guides an expert user as they define a profile,
- showing features that they may use and providing assistance for defining semantic annotation requirements.
-
-<div align="center"><img src="/img/component-profile-editor.png" alt="Component Profile Editor" width="600" /></div>
diff --git a/content/documentation/components/component-validator.md b/content/documentation/components/component-validator.md
deleted file mode 100644
index 098d1b0..0000000
--- a/content/documentation/components/component-validator.md
+++ /dev/null
@@ -1,30 +0,0 @@
-Title: Component validator
-Notice: Licensed to the Apache Software Foundation (ASF) under one
- or more contributor license agreements. See the NOTICE file
- distributed with this work for additional information
- regarding copyright ownership. The ASF licenses this file
- to you under the Apache License, Version 2.0 (the
- "License"); you may not use this file except in compliance
- with the License. You may obtain a copy of the License at
- .
- http://www.apache.org/licenses/LICENSE-2.0
- .
- Unless required by applicable law or agreed to in writing,
- software distributed under the License is distributed on an
- "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- KIND, either express or implied. See the License for the
- specific language governing permissions and limitations
- under the License.
-
-The Taverna Component Validator is a tool and library for checking whether a
- [Taverna Component](/documentation/components) satisfies the component profile defined by the family of which it is a member.
-It applies a number of checks to the component such that when they are all satisfied,
- the component can be considered to be a high-quality member of the component family,
- and provides human-readable descriptions of the conditions that are checked and whether they were satisfied or not.
-
-
-
-We currently have the validator deployed on
- [myExperiment.org](http://www.myexperiment.org) as an integrated feature of the metadata displayed about components.
-
-
diff --git a/content/documentation/components/index.md b/content/documentation/components/index.md
deleted file mode 100644
index b5f74e9..0000000
--- a/content/documentation/components/index.md
+++ /dev/null
@@ -1,161 +0,0 @@
-Title: Workflow Components
-Notice: Licensed to the Apache Software Foundation (ASF) under one
- or more contributor license agreements. See the NOTICE file
- distributed with this work for additional information
- regarding copyright ownership. The ASF licenses this file
- to you under the Apache License, Version 2.0 (the
- "License"); you may not use this file except in compliance
- with the License. You may obtain a copy of the License at
- .
- http://www.apache.org/licenses/LICENSE-2.0
- .
- Unless required by applicable law or agreed to in writing,
- software distributed under the License is distributed on an
- "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- KIND, either express or implied. See the License for the
- specific language governing permissions and limitations
- under the License.
-
-[TOC]
-
-## Overview
-Taverna Workflow Components are a system for creating shareable, reusable,
- encapsulated sub-workflows that perform clearly defined tasks while abstracting
- the details of how those tasks are performed.
-They are an integrated feature of Taverna since Workbench 2.5.0 and Server 2.5.4.
-
-Taverna's system of service components was developed as part of the BioVeL and SCAPE projects. They consist of tools for the creation, management and use of workflow components,
- along with a repository for the storage and sharing of those components.
-Workflow components within a given component family will work together cleanly,
- for example, by adhering to a tidy type system and being well described.
-
-## Requirements
-
-A set of minimal functional requirements for service component management has been developed. These requirements are
- based upon previous component-related work carried out as part of the e-Lico project as well as an examination of the needs of BioVeL and SCAPE.
-
-The requirements include:
-
- - The ability to create components
- - The specification of the characteristics that are necessary for a set of components to
- ‘play’ together – called a ‘component profile’
- - Creating a component so it complies with a given profile
- - Checking that a component complies with a given profile
- - Publishing a component
- - Discovering a component
- - Including a component in a workflow
- - Executing the component within a workflow run
-
-<img class="aligncenter" title="The Model of Components" src="/img/registry.png" alt=""
- width="433" height="251" />
-
-## Workflows
-### Example workflow with components
-
-This is an example workflow that includes components, with internal ports hidden for simplicity:
-
-<img class="alignnone" title="Componentized Workflow" src="/img/component_b_1.png" alt=""
- width="679" height="294" />
-
-Without components, using the same view, it would instead look like this:
-
-[<img class="aligncenter" title="Un-componentized Workflow" src="/img/component_c.png" alt="" width="245" height="526" />](http://www.taverna.org.uk/pages/wp-content/uploads/2013/05/component_c.png)
-
-### Including a component in a workflow
-
-A component can be added into a Taverna workflow in the same way as an ordinary service:
- by dragging it from the service panel of the workbench into the workflow design view.
- *Although it may be realized internally as a workflow,
- a user sees it as a ‘black box’ and cannot (normally) edit the component’s workflow.*
-
-<img class="aligncenter" src="/img/arch3.png" alt="" width="500" height="401" />
-
-It is intended that there will be consistency checks to ensure components are only plugged
- together in a sensible manner, and for the discovery of (and connection to) suitable components
- based upon existing workflow structure.
-
-### Executing a component in a workflow run
-
-When a component is invoked during a workflow run, the underlying workflow is called with the
- corresponding data.
-The results of the workflow are used as the output data for the component invocation.
-*The user sees the component invocation as a ‘black box’ and cannot see details of
- what happens inside.*
-
->If you publish a workflow containing a component, you *must* make sure the
- component is publicly readable in a globally-accessible component registry;
- myExperiment is such a suitable registry.
-
-## Components
-### Component creation
-
-It was decided that the majority of the information necessary for a component will be specified
- as a Taverna workflow.
-This allows complex internal component functionality and removes the need for extensive new
- software to design components.
-
-<img class="aligncenter" src="/img/arch1.png" alt="" width="340" height="433" />
-
-### Component profile
-
-A specification of the format for the component profile has been agreed.
-The format is in XML and an XML schema (xsd) has been created.
-An example [component profile](http://www.myexperiment.org/files/905/versions/1/download/Characterisation%20Component.xml)
- is available.
-Components that share a profile will be collected together into component families.
-A [component profile editor](/documentation/components/component-profile-editor)
- is being developed.
-
-<p style="text-align: center;">
-<img class="aligncenter" src="/img/arch2.png" alt="" width="359" height="412" />
-</p>
-
-The SCAPE project has an
- [extended discussion of component profiles](https://github.com/openpreserve/scape-component-profiles)
- available.
-
-### Component creation against a profile
-
-In order to conform to a component profile, it can be necessary to make semantic annotations
- parts of the corresponding workflow.
-For example, the annotation of the type of format in which data is output by a port or
- a service with the task it performs.
-
-The component profile specifies the ontologies that will be used for the components within the
- family, the correspondence between object classes within a workflow
- (input port, service etc.) and the concepts within the ontologies.
-
-### Checking a component against a profile
-
-Although the components will be modified using a chosen profile,
- it is unlikely that the components can be assured as being ‘correct by construction’.
-For this reason, a separate
- [component validator](/documentation/components/component-validator)
- is being implemented.
-The component validator is included within
- [myExperiment](http://www.myexperiment.org).
-
-### Publishing a component
-
-Since components are realized as ‘extensions’ to Taverna workflows,
- it was decided that rather than using a separate component repository,
- the extensive capabilities of myExperiment would be used.
-Thus a component is currently published and shared on myExperiment as (a pack containing)
- a workflow.
-The components themselves are items within a pack corresponding to the component family.
-
-To facilitate the development of components, a workflow can also be saved to the user’s local
- machine.
-
-When a user publishes a component either to myExperiment or to their local file system,
- their service panel is updated to reflect the new component.
-
-### Discovering a component
-
-Since component families are realized as packs on myExperiment
- (or by analogous structures in the user’s file system),
- we use the existing Taverna code to talk to the myExperiment REST interface to give users
- access to families of components.
-Users can then see the discovered families of components via the Taverna Workbench service
- panel, and the components within those families.
-A component can then be added to a workflow.
