EN

This page holds a translation to french of the "Overview" section of the OSLC Core Specification Version 2.0. This translation is based on rev. 22 of that page. Only the original english version of the specifications is authoritative. This translation is provided for convenience only.

FR

Cette page contient une traduction en français de "Overview" section of the OSLC Core Specification Version 2.0. Cette traduction est basée sur la rev. 22 de cette page. Seul l'original en anglais des spécifications fait autorité. Cette traduction est seulement fournie par commodité.

Introduction

L’initiative « Open Services for Lifecycle Collaboration » (OSLC) crée une famille de spécifications de services web pour des produits, services et autres outils qui soutiennent toutes les phases du cycle de vie des logiciels et produits. L’objectif de ces spécifications est de permettre l’intégration entre des produits qui opérent la « gestion du cycle de vie des applications » (Application Life-cycle Management – ALM) ou la « gestion du cycle de vie du produit » (Product Life-cycle Management – PLM). Chaque portion du cycle de vie et chaque domaine ont leurs propres groupes et spécifications, par exemple on trouve « Gestion des Changements » (Change Management), « Gestion de la Qualité » (Quality Management), « Estimations et Mesure » (Estimation & Measurement), etc. Chacune des spécifications de domaines est construite sur la base des présentes spécifications de base.

Cette « Spécification de base d’OSLC » (OSLC Core Specification) définit les caractéristiques communes que l’on peut s’attendre à voir supportées par chaque Service OSLC, en utilisant la terminologie issue du World Wide Web Consortium (W3C). La terminologie nouvelle que nous introduisons peut être retrouvée dans la section de glossaire ci-dessous. Cette présente spécification concerne principalement les Services OSLC, elle spécifie ce que les Services OSLC doivent (MUST), devraient (SHOULD) et peuvent (MAY) paire. Elle contient également certaines exigences concernant d’autres spécifications OSLC et pour les Clients OSLC.

Les Services OSLC sont accessibles par le biais d’une « ressource Fournisseur de Service » (Service Provider ressource) qui décrit les Services offerts. Chaque Service peut fournir des « Fabriques de Création » (Creation Factories) pour la création de ressources, des « Capacités de Requêtage » (Query Capabilities) pour la recherche de ressources, et des « Dialogues d’IHM Déléguées » (Delegated UI Dialogs) pour permettre aux clients de créer et sélectionner des ressources via une IHM Web. Les Query Capabilities et les Creation Factories peuvent fournir des « Formes de Ressources » (Resource Shapes) qui décrivent les propriétés des ressources gérées par le service. Ceci est illustré dans le diagramme ci-dessous. Voir la section suivante sur les Service Provider Resources pour une description plus complète de ces concepts.

Concepts et relations dans la spécification de base OSLC

Cette spécification définit une terminologie et des règles pour la définition de ressources en termes de noms de propriétés et de types de valeurs qui sont autorisés ou exigés. Les spécifications de domaines OSLC devront utiliser ces règles et cette terminologie pour décrire leurs ressources. Voir la section sur les Ressources Définies par OSLC ("OSLC Defined Resources") pour plus de détails sur ce sujet.

Cette spécification définit également des règles pour la création de représentations de ressources aux formats RDF/XML, JSON, Atom et Turtle. Les spécifications de domaines OSLC devront se référer à ces règles quand elles décrivent la façon dont leurs ressources doivent être représentées. Voir la section sur la Représentation des Ressources Définies par OSLC ("OSLC Defined Resource Representations") pour les règles de représentation et des exemples pour chaque format.

À propos du numéri de version. Nous utilisons le numéro de version "2.0é bien qu'il n'y ait jamais eu de spécification OSLC Core Version 1.0. Nous faisons ceci car cette spécification de base OSLC (OSLC Core) a été écrite après qu'une série de spécifications de domaines en versions 1.0 aient été finalisées par les groupes de travail OSLC. Les versions 2.0 des spécifications de domaines seront toutes basées sur cette Spécification de base (Core Specification) et pour éviter toute confusion cette spécification sera aussi connue comme Version 2.0.

À propos de RDF. Le modèle de données basé sur des ressources et propriétés utilisé dans les ressources OSLC est basé sur Resource Description Framework (RDF) et OSLC exige des représentations RDF, mais OSLC utilise une portion limitée des concepts de RDF et n’exige pas des implémentations de fournir un stockage de triplets RDF ni un moteur de requêtage SPARQL.

Considérations relatives à la conception

Les fondements philosophiques d’OSLC consistent à s’appuyer sur l’architecture du World Wide Web, puissante et qui passe à l’échelle, et à faire les choses les plus simples possibles qui marchent.

S’appuyer sur le WWW. OSLC s’appuie sur l’architecture du WWW et s’inscrit dans les principes architecturaux REST. Ceci signifie que les services OSLC fournissent une interface HTTP uniforme, que les URIs OSLC sont stables et opaques et, en pour faire simple, qu’OSLC fonctionne comme le Web.

Faire simple. Faire les choses les plus simples qui puissent éventuellement fonctionner a quelques répercussions en ce qui concerne OSLC. Cela signifie commencer avec des concepts simples et existants. Par exemple, nous modélisons tout comme étant une ressource avec des valeurs de propriétés et ne nous écartons pas de ce modèle. Faire simple signifie aussi s’appuyer sur des spécifications bien définies et reconnues, mais aussi prendre soin de limiter le nombre des spécifications auxquelles on se réfère. Cette simplicité est destinée à permettre un couplage faible et à rendre la vie plus facile à tout le monde: les groupes de travail des domaines OSLC, le travail d’implémentation des services OSLC et les développeurs de clients OSLC.

Satisfaire des schémas différents. En raison de la variété des domaines OSLC, qui couvrent les cycles de vie et les plate-formes, OSLC doit fonctionner pour des systèmes avec des schémas de données très différents ou pas de schémas du tout. La flexibilité est nécessaire, mais certains services OSLC doivent pouvoir offrir des informations de formes de ressources de façon à ce que des clients puissent apprendre quelles propriétés sont autorisées ou requises pour la création des ressources, le requêtage ou le reporting.

Satisfaire des représentations différentes. Différentes plate-formes clientes peuvent demander ou au moins préférer différentes représentations. Par exemple, dans un navigateur, les formats de représentation JSON ou Atom peuvent être plus adaptés. Les services OSLC seront tous compatibles avec RDF/XML et peuvent supporter d’autres formats comme JSON, Atom et Turtle.

S’aligner sur l’initiative Linked Data du W3C. Au lieu de définir un nouveau modèle de données, l’approche par ressource et valeur de propriété d’OSLC est basée sur le modèle de données du standard industriel Resource Description Framework (RDF). Ce modèle permet à OSLC de rester simple, de s’appuer sur le WWW et de satisfaire des schémas différents.

EN

END OF TRANSLATION so far. Any contribution for the rest of the Overview section much welcome.

FR

FIN DE LA TRADUCTION jusqu'à présent. Toute contribution pour le reste de la section Introduction est vraiment bienvenue.

Glossary of terms

This is a guide to some of the terminology used in this document. The following definitions are standard W3C concepts. OSLC uses these concepts without modification – their definitions are summarized here for the convenience of the reader. See http://www.w3c.org.

• Resource: A network data object or service that can be identified by a URI. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, resolutions) or vary in other ways. (reference: HTTP)

• Representation: An HTTP payload entity, included in an HTTP response, that is subject to content negotiation. There may exist multiple representations. associated with a particular HTTP response status. (reference: HTTP)

• URI: Uniform Resource Identifiers are simply formatted strings which identify--via name, location, or any other characteristic -- a resource (reference: HTTP)

Here are the OSLC specific terms used in this specification:

• OSLC Domain: an OSLC Domain is one ALM or PLM topic area such as Change Management, Requirements management or Automation. Each OSLC Domain will have its own OSLC specification that complies with this Core specification.

• OSLC Service: a set of capabilities that enable a web client to create, retrieve, update and delete resources managed by an ALM or PLM product or online service offering and associated with one OSLC Domain.

• OSLC Service Provider: a product or online service offering that provides an implementation of one or more OSLC Services, which may themselves implement different OSLC Domain specifications.

• OSLC Resource: a resource that is managed by an OSLC Service, may have properties and may link to other resources including those provided by other OSLC Services.

• OSLC Defined Resource: a resource that is either defined by an OSLC specification, defined by an OSLC Resource Shape or both.

• OSLC Defined Properties: resource properties that are defined by an OSLC specification, defined by an OSLC Resource Shape or both.

• OSLC Resource Shape: defines the set of OSLC Properties expected by a particular service or operation and for each their value types, allowed values, cardinality and optionality. Examples of such operations include OSLC Creation Resource and Query Resource. Other examples might include applications that display data in tables.

• OSLC Creation Factory. An OSLC Service may provide one or more creation factories to enable the creation of new resources. A creation factory provides a URI used to create new resources via HTTP POST and may also provide Resource Shapes that describe the types of resources that may be created.

• OSLC Query Capability: An OSLC Service may provide one or more query capabilities to enable query of resources. A query capability provides a base URI for forming query resource URIs and, optionally, Resource Shapes that describe the property values that may be expected in the resources that are queryable via the query capability.

• OSLC Response Info Resource: An OSLC Defined Resource that provides information about a paged resource representation, e.g. the next page in a multi-page query result representation.

Notation and Conventions

The key words "MUST", "MUST NOT", "REQUIRED, SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in RFC2119.

-- OlivierBerger - 10 Sep 2010

• French translation