FR2826748A1 - Description d'une interface applicable a un objet informatique - Google Patents
Description d'une interface applicable a un objet informatique Download PDFInfo
- Publication number
- FR2826748A1 FR2826748A1 FR0108771A FR0108771A FR2826748A1 FR 2826748 A1 FR2826748 A1 FR 2826748A1 FR 0108771 A FR0108771 A FR 0108771A FR 0108771 A FR0108771 A FR 0108771A FR 2826748 A1 FR2826748 A1 FR 2826748A1
- Authority
- FR
- France
- Prior art keywords
- function
- language
- xml
- result
- interface
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/31—Programming languages or programming paradigms
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/80—Information retrieval; Database structures therefor; File system structures therefor of semi-structured data, e.g. markup language structured data such as SGML, XML or HTML
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/33—Intelligent editors
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
- G06F9/4482—Procedural
- G06F9/4484—Executing subprograms
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Stored Programmes (AREA)
- Devices For Executing Special Programs (AREA)
- Document Processing Apparatus (AREA)
- Information Transfer Between Computers (AREA)
Abstract
L'invention concerne un procédé de description d'une fonction applicable à un objet informatique, la fonction était appelable dans un langage de balisage, la fonction étant initialement exprimée dans un langage de programmation prédéterminé et différent du langage de balisage, caractérisé en ce qu'il comporte les étapes de : - définition (E4) d'un élément décrivant la fonction, dans un langage de schéma associé au langage de balisage, - définition (E6) des arguments de la fonction, dans ledit langage de schéma, et, si la fonction produit un résultat, - définition (E10) de l'élément décrivant le résultat de la fonction, dans ledit langage de schéma.
Description
<Desc/Clms Page number 1>
La présente invention concerne d'une manière générale la description d'une interface applicable à un objet informatique dans un langage de schéma associé à un langage de balisage.
Dans un système orienté objet (en anglais"object oriented system"), l'objet informatique est un élément comprenant des données, également appelé attributs, et des fonctions (en anglais"Functions"ou"Method") utilisant éventuellement des paramètres ou arguments ("input arguments"en anglais).
De manière classique, ces fonctions peuvent être appelées ou invoquées (en anglais"invoked") pour manipuler les données de l'objet.
Une interface est un ensemble de fonctions applicables à un objet.
Un langage de balisage connu sera plus particulièrement considéré dans la suite. Il s'agit du langage XML (d'après l'anglais Extended Markup Language ).
Ce langage est défini par une norme, dite norme XML dont une description peut être trouvée via internet à l'adresse : http : //www. w3. orq/TR/2000/REC-xml-20001006).
La norme XML définit une syntaxe permettant de structurer des documents à l'aide de balises délimitées par les signes < et > (exemple : < balise > ). Ces balises sont regroupées par paires de balises ouvrantes ( < balise > ) et fermantes ( < /balise > ). Une balise XML est un élément constitué par une balise ouvrante, la balise fermante correspondante et l'ensemble du contenu délimité par ces balises. Ce contenu est composé d'autres éléments et/ou de texte pur.
<Desc/Clms Page number 2>
Une balise sans contenu peut être représentée par une balise vide < balise/ > .
Un document XML est constitué d'un élément principal.
Un langage de schéma XML permet de décrire un langage XML. Il existe plusieurs langages de schéma XML. Un exemple de langage de schéma XML est décrit dans la norme XML Schema , dont la version du 2 mai 2001 est disponible via internet à l'adresse suivante http ://www. w3. orgITR/2001/xmlschema-1.
Un document écrit dans un langage de schéma XML est couramment appelé schéma XML. Un schéma XML décrit la structure d'un ensemble de document XML. Un schéma XML est la description des balises autorisées dans un document conforme à ce langage XML et de leurs imbrications possibles. Un document XML respectant la structure définie par un schéma XML est dit valide par rapport à ce schéma XML.
Dans ce contexte, la demande de brevet français n 99 08155 déposée par la demanderesse décrit un procédé d'exécution à distance d'une fonction sur un objet informatique dans un réseau de communication. Plus particulièrement, ce document propose une méthode de description des interfaces d'un objet basée sur un langage XML. Le langage XML utilisé est spécifique à cette application et n'offre qu'un ensemble limité de types possibles pour les paramètres d'entrée et de sortie des fonctions.
D'autre part, une spécification écrite par les sociétés IBM et Microsoft, appelée WSDL (d'après l'anglais Web Services Description Langage) propose une méthode de description de services utilisant la syntaxe XML. Un service est caractérisé par la description du document qu'il reçoit en entrée et du document qu'il produit en sortie. Ces documents sont des documents XML dont la structure peut être classiquement décrite par des
schémas XML.
schémas XML.
Il est à noter que cette spécification n'utilise pas la notion d'objet. Le langage de schéma XML est utilisé selon sa fonction connue, c'est-à-dire pour décrire la structure de documents XML. Dans le cadre de cette spécification, les documents décrits sont les documents traités et produits par un service.
<Desc/Clms Page number 3>
Par ailleurs, le brevet américain US 6 125 391 décrit l'utilisation de documents pour réaliser des transactions entre partenaires commerciaux via un réseau. De manière similaire à la spécification WSDL, une transaction est décrite par ses documents d'entrée et de sortie.
Là encore, la notion d'objet n'est pas utilisée et le langage de schéma XML est utilisé selon sa fonction connue, c'est-à-dire pour décrire la structure de documents XML.
La présente invention vise à remédier aux inconvénients de la technique antérieure, en fournissant un procédé et un dispositif de description d'une fonction applicable à un objet informatique.
A cette fin, l'invention propose un procédé de description d'une fonction applicable à un objet informatique, la fonction était appelable dans un langage de balisage, la fonction étant initialement exprimée dans un langage de programmation prédéterminé et différent du langage de balisage, caractérisé en ce qu'il comporte les étapes de : - définition d'un élément décrivant la fonction, dans un langage de schéma associé au langage de balisage, - définition des arguments de la fonction, dans ledit langage de schéma, et, si la fonction produit un résultat, - définition de l'élément décrivant le résultat de la fonction, dans ledit langage de schéma.
Corrélativement, l'invention concerne un dispositif de description d'une fonction applicable à un objet informatique, la fonction était appelable dans un langage de balisage, la fonction étant initialement exprimée dans un langage de programmation prédéterminé et différent du langage de balisage, caractérisé en ce qu'il comporte : - des moyens de définition d'un élément décrivant la fonction, dans un langage de schéma associé au langage de balisage, - des moyens de définition des arguments de la fonction, dans ledit langage de schéma, et, si la fonction produit un résultat,
<Desc/Clms Page number 4>
- des moyens de définition de l'élément décrivant le résultat de la fonction, dans ledit langage de schéma.
Grâce à l'invention, les fonctions sont décrites à l'aide d'un langage de schéma qui est un langage standard, ce qui permet d'utiliser tous les outils existant pour traiter ce langage.
La conception et la programmation d'une interface sont simplifiées.
Il est notamment possible de définir de nouveaux types d'éléments, de valider des appels de fonction, ces fonctions permettant de réaliser des traitements, par exemple sur des image, qui auparavant étaient complexes, sinon difficiles, à réaliser.
Selon des caractéristiques préférées et alternatives, lorsqu'une fonction produit un résultat, la définition d'un élément décrivant un appel de cette fonction comporte un attribut spécifique pour indiquer quel élément décrit le résultat de cet appel ou un élément décrivant un appel de cette fonction et l'élément décrivant son résultat sont mis en relation grâce à des éléments documentaires du langage de schéma. Ainsi, un appel de fonction et son résultat son liés.
Selon une caractéristique préférée, la définition d'un élément d'une fonction a un type particulier qui permet de caractériser cet élément comme décrivant une fonction.
Selon une autre caractéristique préférée, au moins une fonction faisant partie d'une interface, l'invention comporte la mémorisation de l'interface dans le langage de schéma et dans le langage de programmation.
Le dispositif de description comporte des moyens de mises en oeuvre des caractéristiques précédentes.
L'invention concerne aussi un procédé d'obtention, par un terminal client, d'une interface d'un objet, ladite interface comportant au moins une fonction décrite par le procédé de description précédemment exposé, caractérisé en ce qu'il comporte la traduction de ladite interface dans un langage de programmation différent du langage de schéma.
<Desc/Clms Page number 5>
Selon une caractéristique préférée, le procédé d'obtention comporte la mémorisation de l'interface dans le langage de schéma et dans le langage de programmation.
Selon une caractéristique préférée, le langage de balisage est un langage XML et le langage de schéma associé est un langage de schéma XML. Les schémas XML permettent de valider les documents contenant les appels de fonction et les documents contenant les résultats de fonction.
L'invention concerne aussi un dispositif d'obtention comportant des moyens de mises en oeuvre des caractéristiques précédentes.
Le dispositif de description, le procédé et le dispositif d'obtention présentent des avantages analogues à ceux précédemment présentés.
L'invention concerne aussi un ordinateur incluant le dispositif selon l'invention, ou des moyens de mise en oeuvre du procédé selon l'invention. Les avantages de l'ordinateur sont identiques à ceux précédemment exposés.
Un moyen de stockage d'information, lisible par un ordinateur ou par un microprocesseur, intégré ou non au dispositif, éventuellement amovible, mémorise un programme mettant en oeuvre le procédé selon l'invention.
Un programme d'ordinateur lisible par un microprocesseur et comportant une ou plusieurs séquence d'instructions est apte à mettre en oeuvre les procédés selon l'invention.
Les caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture d'un mode préféré de réalisation illustré par les dessins ci-joints, dans lesquels : - la figure 1 est un mode de réalisation d'un dispositif mettant en oeuvre l'invention, - la figure 2 représente un réseau d'ordinateurs mettant en oeuvre l'invention, - la figure 3 est une représentation schématique des relations entre des documents, selon l'invention, - la figure 4 représente des exemples de documents utilisés selon l'invention,
<Desc/Clms Page number 6>
- les figures 5 et 6 représentent des tableaux mémorisés dans un ordinateur serveur, selon l'invention, - la figure 7 représente un mode de réalisation de procédé selon l'invention, - la figure 8 représente un mode de réalisation de procédé de génération d'une représentation d'un type de données en schéma XML, - la figure 9 représente un tableau mémorisé dans un ordinateur client, selon l'invention, - la figure 10 représente un mode de réalisation de procédé d'obtention des interfaces d'un objet par un ordinateur client.
Selon le mode de réalisation choisi et représenté à la figure 1, un dispositif mettant en oeuvre l'invention est par exemple un micro-ordinateur 1 connecté à différents périphériques. Cet ordinateur peut être un client ou un serveur, dans le cadre de l'invention.
Le dispositif 1 comporte une carte réseau 107 reliée à un réseau 4 apte à transmettre des données numériques à traiter ou inversement à transmettre des données traitées par le dispositif. Le dispositif 1 comporte également un moyen de stockage 104 tel que par exemple un disque dur. Il comporte aussi un lecteur 105 de disque 2. Ce disque 2 peut être une disquette, un CD-ROM, ou un DVD-ROM, par exemple. Le disque 2 comme le disque dur 104 peuvent contenir des données traitées selon l'invention ainsi que le ou les programmes mettant en oeuvre l'invention qui, une fois lu par le dispositif 1, sera stocké dans le disque dur 104. Selon une variante, le programme permettant au dispositif de mettre en oeuvre l'invention, pourra être stocké en mémoire morte 102 (appelée ROM sur le dessin). En seconde variante, le programme pourra être reçu pour être stocké de façon identique à celle décrite précédemment par l'intermédiaire du réseau de communication 4.
Le dispositif 1 comporte un lecteur de carte 106 capable de lire une carte 3.
<Desc/Clms Page number 7>
Ce même dispositif possède une carte graphique 108 à laquelle sont reliés un écran 5 et un dispositif vidéo 6, tel qu'un magnétoscope ou une caméra, par exemple.
Le dispositif 1 possède une carte d'entrée/sortie 109 à laquelle sont reliés par exemple un clavier 7, une souris 8, un appareil photographique 9, une imprimante 10.
Le dispositif 1 possède une carte audio 110 à laquelle est relié un dispositif audio 11, tel qu'un microphone par exemple.
L'unité centrale 100 (appelée CPU sur le dessin) exécute les instructions relatives à la mise en oeuvre de l'invention, instructions stockées dans la mémoire morte 102 ou dans les autres éléments de stockage. Lors de la mise sous tension, les programmes de traitement stockés dans une mémoire non volatile, par exemple la ROM 102, sont transférés dans la mémoire vive RAM 103 qui contiendra alors le code exécutable de l'invention ainsi que des registres pour mémoriser les variables nécessaires à la mise en oeuvre de l'invention.
De manière plus générale, un moyen de stockage d'information, lisible par un ordinateur ou par un microprocesseur, intégré ou non au dispositif, éventuellement amovible, mémorise un programme mettant en oeuvre le procédé selon l'invention.
Le bus de communication 101 permet la communication entre les différents éléments inclus dans le micro-ordinateur 10 ou reliés à lui. La représentation du bus 101 n'est pas limitative et notamment l'unité centrale 100 est susceptible de communiquer des instructions à tout élément du microordinateur 1 directement ou par l'intermédiaire d'un autre élément du microordinateur 1.
Selon l'invention, lorsque le dispositif est dans un terminal serveur, il comporte pour la description, dans un langage de schéma associé à un langage de balisage, d'une fonction applicable à un objet informatique, la fonction étant initialement exprimée dans un langage de programmation prédéterminé et différent du langage de schéma :
<Desc/Clms Page number 8>
- des moyens de définition d'un élément décrivant la fonction, dans ledit langage de schéma, - des moyens de définition des arguments de la fonction, dans ledit langage de schéma, et, si la fonction produit un résultat, - des moyens de définition de l'élément décrivant le résultat de la fonction, dans ledit langage de schéma.
Selon l'invention, lorsque le dispositif est dans un terminal client, il comporte pour l'obtention, par un terminal client, d'une interface d'un objet, ladite interface comportant au moins une fonction décrite par le dispositif dans le terminal serveur, des moyens de traduction de ladite interface dans un langage de programmation différent du langage de schéma.
Le fonctionnement de l'ordinateur dans le cadre de l'invention est exposé dans la suite.
L'invention concerne aussi un programme d'ordinateur adapté à mettre en oeuvre l'invention. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable pour implémenter un procédé selon l'invention. Le programme d'ordinateur est dans ou sur un support d'information qui peut être n'importe quelle entité ou dispositif capable de stocker le programme.
En référence à la figure 2, trois ordinateurs C200, C201 et C202 conformes à l'ordinateur décrit en référence à la figure 1 fournissent des services par l'intermédiaire des objets 0200,0201, 0202,0203 et 0204.
La liste et les caractéristiques des fonctions applicables aux objets sont décrits par les interfaces 1200,1201 et 1203. Un objet réfère aux interfaces qui décrivent les fonctions qui lui sont applicables. Un objet peut référer à une seule interface, par exemple l'objet 0200 ne réfère qu'à l'interface 1200. Un objet peut également référer à plusieurs interfaces, par exemple l'objet 0201
<Desc/Clms Page number 9>
réfère aux interface 1200 et 1201. Un objet peut référer à une interface présente sur le même ordinateur ou sur un ordinateur distant.
En référence à la figure 3, un objet est décrit par un document 300 écrit en un langage de balisage, par exemple un langage XML. Le document 300 est ici un document XML.
Le document 300 réfère à un document représentant une interface 301. Selon l'invention, le document 301 est écrit dans un langage de schéma associé au langage de balisage utilisé. Le document 301 est ici un schéma XML.
Un appel de fonction applicable à l'objet représenté par le document XML 300 est représenté par un document XML 302. Lorsque l'appel de fonction produit un résultat, ce dernier est représenté par un document XML 303.
Le document de description de l'interface 301 permet de valider les documents 302 et 303, c'est-à-dire de vérifier que leur structure est conforme à celle définie par le schéma XML représentant l'interface.
Dans le cas d'un appel de fonction, la validation permet notamment de vérifier que le nombre d'argument passé est correct, que le type des arguments (entier, chaîne de caractères, réel, etc) est correct et que des contraintes sur la valeur des arguments (plage de valeur, etc) sont respectées.
La figure 4 représente des exemples de documents XML utilisés par l'invention.
Le document 400 est la description d'un objet nommé image. Cet objet contient une référence vers son interface, sous la forme d'un attribut (interface="http : //www. crf. canon. fr/imagelnterface. xsd") de l'élément principal (image). La valeur de cet attribut est l'URI (d'après l'anglais Universal Resource Identifier) de l'interface.
En extrayant cette URI de la définition de l'objet, il est possible d'obtenir par une connexion via le réseau Internet la description de l'interface de l'objet.
<Desc/Clms Page number 10>
Si les fonctions applicables à l'objet sont décrites par plusieurs interfaces, l'attribut interface aura pour valeur la liste des URI de ces interfaces.
Par exemple : interface="http : //www. crf. canon. fr/imagetnterface. xsd http : //www. crf. canon. fr/printinq 1 nterface. xsd").
L'interface référencée par l'objet (à l'URI http ://www. crf. canon. fr/imagelnterface. xsd) est décrite par le document 410. Le document 410 est un schéma XML. La première partie 411 de ce document 410 correspond à des définitions générales devant être reproduites dans toutes les descriptions d'interface. Il est possible de regrouper ces définitions dans un document qui sera importé (par un élément import) dans toutes les descriptions d'interface. Le rôle de ces définitions sera expliqué par la suite.
Les parties 412,413 et 414 correspondent respectivement aux descriptions de trois fonctions appelées getWidth , getdimension et rotate . Les parties 412 et 413 comprennent à la fois la description d'un appel de fonction et du résultat de cet appel. La partie 414 ne contient que la description d'un appel de la fonction, la fonction rotate ne retournant aucun résultat.
Un appel de fonction ou un résultat de fonction est décrit en utilisant une définition d'élément XML. L'utilisation d'un langage de schéma XML permet de décrire la structure d'un appel de fonction (liste des paramètres et de leur type) ou d'un résultat de fonction (type du résultat). Deux aspects ne peuvent être spécifiés à l'aide de cette norme : savoir si une définition d'élément XML correspond à un appel de fonction ou à un résultat et connaître le résultat correspondant à un appel de fonction.
Un élément décrivant un appel de fonction a un type dérivant du type function défini dans la partie 411 du document 410. Ce type function permet de déterminer quelles définitions d'élément XML correspondent à des appels de fonction dans le document 410.
D'autre part, la définition d'un élément décrivant un appel de fonction peut contenir un attribut supplémentaire nommé image : resuttType pour
<Desc/Clms Page number 11>
indiquer quel élément décrit le résultat de cet appel. Cet attribut est défini dans la partie 411 du document 410. Son absence indique que la fonction ne retourne aucun résultat. Ainsi, le résultat de la fonction nommée getWidth est décrit par l'élément nommé width , tandis que la fonction nommée rotate ne retourne pas de résultat.
En variante, un appel de fonction et un résultat sont mis en correspondance grâce aux éléments documentaires du langage de schéma XML. Une première variante consiste à ajouter une documentation à chaque description de fonction pour indiquer quel élément décrit son résultat : xsd : element name="getWidth" > < xsd : annotation > < xsd : applnfo > < result > width < /result > < /xsd : appInfo > < /xsd : annotation > < xsd : complexType > < xsd : complexContent > < xsd : extension base="image : function"/ > < /xsd : complexContent > < /xsd : complexType > < /xsd : element >
Une deuxième variante consiste à ajouter au document 410 une documentation mettant en correspondance l'ensemble des descriptions de fonction avec leur éventuel résultat. Il est à noter que cette deuxième variante permet de s'affranchir de l'utilisation du type function , les éléments décrivant une fonction étant identifiés dans la liste constituant la documentation. Dans l'exemple du document 410, la documentation ajoutée serait : < xsd : annotation > < xsd : appInfo > < function > < call > getWidth < /call > < result > width < /result > < /function >
Une deuxième variante consiste à ajouter au document 410 une documentation mettant en correspondance l'ensemble des descriptions de fonction avec leur éventuel résultat. Il est à noter que cette deuxième variante permet de s'affranchir de l'utilisation du type function , les éléments décrivant une fonction étant identifiés dans la liste constituant la documentation. Dans l'exemple du document 410, la documentation ajoutée serait : < xsd : annotation > < xsd : appInfo > < function > < call > getWidth < /call > < result > width < /result > < /function >
<Desc/Clms Page number 12>
< function > < call > getDimension < /call > < result > dimension < / result > < /function > < function > < call > rotate < /call > < /function > < /xsd : appInfo > < /xsd : annotation >
Les documents 420 et 430 correspondent à un appel et un résultat de la fonction nommée getdimension décrite dans la partie 413 du document 410. Ces deux documents XML peuvent être validés par le document 410. Le document 440 correspond quant à lui à un appel de la fonction nommée rotate décrite dans la partie 414 du document 410.
Les documents 420 et 430 correspondent à un appel et un résultat de la fonction nommée getdimension décrite dans la partie 413 du document 410. Ces deux documents XML peuvent être validés par le document 410. Le document 440 correspond quant à lui à un appel de la fonction nommée rotate décrite dans la partie 414 du document 410.
La figure 5 représente un tableau T mémorisé dans la mémoire RAM 103 d'un ordinateur serveur, par exemple l'ordinateur C200 (figure 2). Le tableau T contient les associations entre objets et interfaces.
La première colonne T500 du tableau T comporte les URI sous lesquelles sont respectivement publiés les objets. La deuxième colonne T501 comporte des références respectives aux objets publiés. Une référence pointe sur la représentation interne d'un objet dans la RAM 103 de l'ordinateur C200.
La troisième colonne T502 comporte les URI des interfaces décrivant respectivement les fonctions applicables aux objets.
Ainsi, une ligne du tableau T comporte l'URI sous laquelle est publié un objet, une référence à l'objet publié et l'URI d'une interface décrivant les fonctions applicables à l'objet. Si les fonctions applicables à un objet sont décrites par plusieurs interfaces, le tableau T comporte autant de lignes mettant respectivement en relation cet objet et chacune de ses interfaces.
La figure 6 représente un tableau T'mémorisé dans la mémoire RAM 103 d'un ordinateur serveur par exemple l'ordinateur C200 (figure 2). Le tableau T contient les associations entre les interfaces et leur représentation en langage de schéma XML.
La première colonne T'500 du tableau T'comporte les URI sous lesquelles sont respectivement publiées les interfaces. Il est à noter que ces
<Desc/Clms Page number 13>
URI se retrouvent dans la colonne T502 du tableau T. La deuxième colonne T'501 comporte les représentations en Schéma XML respectives de chaque interface sous forme de fichier texte.
La troisième colonne T'502 comporte les représentations internes des interfaces, par exemple en langage C ou C++.
Ainsi, une ligne du tableau T'comporte l'URI sous laquelle est publiée une interface, la représentation en Schéma XML de cette interface et la représentation interne de l'interface.
La figure 7 représente un mode de réalisation de description d'une interface dans un langage de schéma associé à un langage de balisage, selon l'invention. Ce procédé est mis en oeuvre dans un serveur et comporte des étapes E1 à E12.
Le procédé est réalisé sous la forme d'un algorithme qui peut être mémorisé en totalité ou en partie dans tout moyen de stockage d'information capable de coopérer avec le microprocesseur. Ce moyen de stockage est lisible par un ordinateur ou par un microprocesseur. Ce moyen de stockage est intégré ou non au dispositif, et peut être amovible. Par exemple, il peut comporter une bande magnétique, une disquette ou un CD-ROM (disque compact à mémoire figée).
Comme précisé plus haut, le langage de balisage est plus particulièrement le langage XML et le langage de schéma associé est le langage de schéma XML.
L'étape E1 est l'obtention de l'interface à décrire, par exemple par lecture en mémoire. L'interface est un ensemble de fonctions pouvant être appliquées à un objet informatique. L'interface est exprimée dans un langage de programmation prédéterminé, connu, différent du langage de schéma XML et quelconque, par exemple en langage C ou C++.
Les fonctions de l'interface sont maintenant considérées successivement.
L'étape suivante E2 est la sélection d'une première fonction.
<Desc/Clms Page number 14>
L'étape suivante E3 est la création d'une définition vide de l'élément décrivant la fonction courante. Cette définition est exprimée en langage de schéma XML, sous la forme : < xsd : element name="..." > < xsd : complexType > < xsd : complexContent > < xsd : extension base="image : function" > < /xsd : extension > < /xsd : complexContent > < /xsd : complexType > < /xsd : element > La première ligne est complétée avec le nom de la fonction courante qui est inséré comme valeur de l'attribut name .
L'étape suivanteE4 est un test pour déterminer si la fonction courante possède au moins un argument.
Lorsque la réponse est positive, l'étape E4 est suivie de l'étape E5 qui est la sélection d'un premier argument de la fonction courante.
A l'étape suivante E6, une définition de l'argument courant est créée en langage de schéma XML et ajoutée à la définition créée à l'étape E3.
L'étape E6 est décrite en détail dans la suite.
L'étape suivante E7 est un test pour déterminer s'il reste au moins un argument à traiter.
Lorsque la réponse est positive, cette étape est suivie de l'étape E8, à laquelle un argument suivant est considéré. Cette étape est suivie de l'étape E6 précédemment décrite.
Lorsque la réponse est négative à l'étape E7, c'est-à-dire il n'y a plus d'argument à considérer, l'étape E7 est suivie de l'étape E9. De même, lorsque la réponse est négative à l'étape E4, cette étape est suivie de l'étape E9.
L'étape E9 est un test pour vérifier si l'appel de la fonction courante produit un résultat.
<Desc/Clms Page number 15>
Lorsque la réponse est positive, alors cette étape est suivie de l'étape E10 à laquelle une définition du résultat est créée en langage de schéma XML.
La première ligne de la définition de la fonction courante est alors complétée en ajoutant un attribut image : resultType dont la valeur est le nom de l'élément décrivant le résultat : < xsd : element name=II... 1I image : resultType="..." >
La création de la définition du résultat est ensuite analogue à l'étape E6 et sera décrite en détail dans la suite.
La création de la définition du résultat est ensuite analogue à l'étape E6 et sera décrite en détail dans la suite.
L'étape E10 est suivie de l'étape E11 qui est un test pour vérifier s'il reste au moins une fonction à traiter. De même, lorsque la réponse est négative à l'étape E9, c'est-à-dire un appel de la fonction courante ne produit pas de résultat, l'étape E9 est suivie de l'étape E11.
Lorsque la réponse est positive à l'étape EU, cette étape est suivie de l'étape E12 pour considérer une fonction suivante. Cette étape est suivie de l'étape E3 précédemment décrite.
Lorsque toutes les fonctions de l'interface courante ont été traitées, la réponse à l'étape E11 est négative et le traitement est terminé. Bien entendu, l'interface est mémorisée dans le tableau T'précédemment décrit.
Les étapes E6 et E10 sont maintenant détaillées en référence à la figure 8, sous la forme d'un algorithme comportant des étapes E70 à E81.
La description en langage de schéma XML d'un argument ou d'un résultat est réalisée en fonction de son type. On décrit dans la suite la figure en référence à un argument, mais les étapes sont identiques pour décrire un résultat de fonction.
L'étape E70 est un test pour vérifier si le type de l'argument courant est complexe. Un type complexe est composé de plusieurs champs. Chaque champ a son propre type.
<Desc/Clms Page number 16>
Lorsque la réponse est positive, cela signifie que l'argument courant comporte plusieurs champs et cette étape est suivie de l'étape E71 à laquelle une définition d'élément correspondant à ce type complexe est créée en langage de schéma XML.
L'étape suivante E72 est la sélection d'un premier champ de l'argument courant.
A l'étape suivante E73, une définition du champ est créée en langage de schéma XML et ajoutée à la définition du type courant.
L'étape E73 est un appel de l'algorithme de description de type en langage de schéma XML. En d'autres termes, l'étape E73 se branche à l'étape E70, pour traiter le champ courant en fonction de son type.
L'étape suivante E74 est un test pour vérifier s'il reste au moins un champ de l'argument de type complexe courant à traiter.
Lorsque la réponse est positive, alors cette étape est suivie de l'étape E75 à laquelle un champ suivant est considéré. L'étape E75 est suivie de l'étape E73 précédemment décrite.
Lorsque tous les champs de l'argument de type complexe courant ont été décrits en langage de schéma XML, c'est-à-dire lorsque la réponse est négative à l'étape E74, alors le traitement de l'argument courant est terminé.
Lorsque la réponse est négative à l'étape E70, le type de l'argument courant n'est pas complexe. Dans ce cas, cette étape est suivie de l'étape E76 qui est un test pour vérifier si le type est une collection. Une collection est un ensemble de valeurs d'un même type.
Lorsque la réponse est positive, alors cette étape est suivie de l'étape E77 à laquelle une définition d'élément correspondant à ce type collection est créée en langage de schéma XML.
A l'étape suivante E78, une définition d'élément imbriqué est créée en langage de schéma XML et ajoutée à la définition du type collection courant.
L'étape E78 est un appel de l'algorithme de description de type en langage de schéma XML. En d'autres termes, l'étape E78 se branche à l'étape E70, pour traiter l'élément imbriqué en fonction de son type.
Ainsi, par exemple, un tableau d'entier est décrit par la définition :
<Desc/Clms Page number 17>
< xsd : element name="tableauEntier" > < xsd : complexType > < xsd : sequence minOccurs="O"maxOccurs="unbounded" > < xsd : element name="element" type="xsd : integer"/ > < /xsd : sequence > < /xsd : complexType > < /xsd : element >
Lorsque la réponse est négative à l'étape E76, cette étape est suivie de l'étape E79 qui est un test pour déterminer si l'argument courant a un type simple connu, c'est-à-dire correspondant à un type défini par les schémas XML.
Lorsque la réponse est négative à l'étape E76, cette étape est suivie de l'étape E79 qui est un test pour déterminer si l'argument courant a un type simple connu, c'est-à-dire correspondant à un type défini par les schémas XML.
Un élément de type simple ne comporte pas d'attribut ni de sous-élément. Des types simples connus sont par exemple les entiers, les réels, les chaînes de caractères.
Lorsque la réponse est positive, cette étape est suivie de l'étape E80 qui est la création d'une définition d'élément possédant ce type simple.
Lorsque la réponse est négative à l'étape E79, cette étape est suivie de l'étape E81 qui est la création d'une définition d'élément correspondant à une référence distante. Cet élément contient une URI à partir de laquelle pourra être téléchargé l'objet référencé.
La figure 9 représente un tableau Tc'analogue similaire au tableau T'de la figure 6, mais est mémorisé dans la mémoire RAM 103 d'un ordinateur client.
Le tableau Tc'permet à l'ordinateur client de conserver les descriptions des interfaces qu'il rencontre. Les interfaces sont mémorisées à la fois sous forme de description en schéma XML qui est la description telle que l'ordinateur client l'obtient depuis l'ordinateur serveur et sous forme interne, cette description étant reconstruite à partir de la description en schéma XML.
<Desc/Clms Page number 18>
La figure 10 représente un procédé d'obtention des interfaces d'un objet par un ordinateur client, sous la forme d'un algorithme comportant des étapes E20 à E29. Ce procédé a pour but d'obtenir l'ensemble des interfaces décrivant les fonctions applicables à un objet.
Cet algorithme peut être mémorisé en totalité ou en partie dans tout moyen de stockage d'information capable de coopérer avec le microprocesseur. Ce moyen de stockage est lisible par un ordinateur ou par un microprocesseur. Ce moyen de stockage est intégré ou non au dispositif, et peut être amovible. Par exemple, il peut comporter une bande magnétique, une disquette ou un CD-ROM (disque compact à mémoire figée).
L'étape E20 est la réception de la description d'un objet sous la forme d'un document XML par exemple en réponse à une requête. L'ordinateur client reçoit par exemple le document 400 (figure 4).
L'étape suivante E21 est l'extraction de l'URI d'une première interface depuis le document XML. Par exemple, l'URI : http : //www. crf. canon. fr/imaqel nterface. xsd est extraite du document 400.
L'étape suivante E22 est un test pour déterminer si l'interface courante est mémorisée dans le tableau Tc' (figure 9) présent dans la mémoire RAM de l'ordinateur client.
Lorsque la réponse est négative, l'étape E22 est suivie de l'étape E23 à laquelle une requête est envoyée à l'adresse définie par l'URI précédemment obtenue pour obtenir la description en schéma XML de l'interface.
L'étape suivante E24 est la réception de la description en schéma XML de l'interface. Par exemple, le document 410 est reçu par l'ordinateur client.
A l'étape suivante E25, le schéma XML de l'interface courante est mémorisée dans le tableau Tc'.
L'étape suivante E26 est la traduction du schéma XML de l'interface courante en langage interne, tel que C ou C++ par exemple, pour obtenir une description interne.
<Desc/Clms Page number 19>
A l'étape suivante E27, la description interne de l'interface courante est mémorisée dans le tableau Tc'.
L'étape E27 est suivie de l'étape E28 qui est un test pour déterminer s'il reste au moins une interface à traiter. Si la réponse est positive, alors cette étape est suivie de l'étape E29 à laquelle l'URI d'une interface suivante est extraite. L'étape E29 est suivie de l'étape E22 précédemment décrite.
Lorsque la réponse est positive à l'étape E22, cette étape est également suivie de l'étape E28.
Lorsque la réponse est négative à l'étape E28, alors l'ensemble des interfaces décrivant les fonctionnalités d'un objet a été obtenu par l'ordinateur client.
Bien entendu, la présente invention n'est nullement limitée aux modes de réalisation décrits et représentés, mais englobe, bien au contraire, toute variante à la portée de l'homme du métier.
Claims (21)
1. Procédé de description d'une fonction applicable à un objet informatique, la fonction était appelable dans un langage de balisage, la fonction étant initialement exprimée dans un langage de programmation prédéterminé et différent du langage de balisage, caractérisé en ce qu'il comporte les étapes de : - définition (E4) d'un élément décrivant la fonction, dans un langage de schéma associé au langage de balisage, - définition (E6) des arguments de la fonction, dans ledit langage de schéma, et, si la fonction produit un résultat, - définition (E 10) de l'élément décrivant le résultat de la fonction, dans ledit langage de schéma.
2. Procédé selon la revendication 1, caractérisé en ce que, lorsqu'une fonction produit un résultat, la définition d'un élément décrivant un appel de cette fonction comporte un attribut spécifique pour indiquer quel élément décrit le résultat de cet appel.
3. Procédé selon la revendication 1, caractérisé en ce que, lorsqu'une fonction produit un résultat, un élément décrivant un appel de cette fonction et l'élément décrivant son résultat sont mis en relation grâce à des éléments documentaires du langage de schéma.
4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que la définition d'un élément d'une fonction a un type particulier qui permet de caractériser cet élément comme décrivant une fonction.
<Desc/Clms Page number 21>
5. Procédé selon l'une quelconque des revendications 1 à 4, dans lequel au moins une fonction fait partie d'une interface, caractérisé en ce qu'il comporte la mémorisation de l'interface dans le langage de schéma et dans le langage de programmation.
6. Procédé d'obtention, par un terminal client, d'une interface d'un objet, ladite interface comportant au moins une fonction décrite par le procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce qu'il comporte la traduction (E26) de ladite interface dans un langage de programmation différent du langage de schéma.
7. Procédé d'obtention selon la revendication 6, caractérisé en ce qu'il comporte la mémorisation de l'interface dans le langage de schéma et dans le langage de programmation.
8. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que le langage de balisage est un langage XML et le langage de schéma associé est un langage de schéma XML.
9. Dispositif de description d'une fonction applicable à un objet informatique, la fonction était appelable dans un langage de balisage, la fonction étant initialement exprimée dans un langage de programmation prédéterminé et différent du langage de balisage, caractérisé en ce qu'il comporte : - des moyens de définition d'un élément décrivant la fonction, dans un langage de schéma associé à un langage de balisage, - des moyens de définition des arguments de la fonction, dans ledit langage de schéma, et, si la fonction produit un résultat, - des moyens de définition de l'élément décrivant le résultat de la fonction, dans ledit langage de schéma.
<Desc/Clms Page number 22>
10. Dispositif selon la revendication 9, caractérisé en ce que, lorsqu'une fonction produit un résultat, les moyens de la définition d'un élément décrivant un appel de cette fonction sont adaptés à insérer dans cet élément un attribut spécifique pour indiquer quel élément décrit le résultat de cet appel.
11. Dispositif selon la revendication 9, caractérisé en ce que, lorsqu'une fonction produit un résultat, les moyens de définition sont adaptés à mettre en relation un élément décrivant un appel de cette fonction et l'élément décrivant son résultat grâce à des éléments documentaires du langage de schéma.
12. Dispositif selon l'une quelconque des revendications 9 à 11, caractérisé en ce qu'il est adapté à doter la définition d'un élément d'une fonction d'un type particulier qui permet de caractériser cet élément comme décrivant une fonction.
13. Dispositif selon l'une quelconque des revendications 9 à 12, au moins une fonction faisant partie d'une interface, caractérisé en ce qu'il comporte des moyens (T') de mémorisation de l'interface dans le langage de schéma et dans le langage de programmation.
14. Dispositif d'obtention, par un terminal client, d'une interface d'un objet, ladite interface comportant au moins une fonction décrite par le dispositif selon l'une quelconque des revendications 9 à 13, caractérisé en ce qu'il comporte des moyens de traduction (E26) de ladite interface dans un langage de programmation différent du langage de schéma.
15. Dispositif d'obtention selon la revendication 14, caractérisé en ce qu'il comporte des moyens de mémorisation de l'interface dans le langage de schéma et dans le langage de programmation.
<Desc/Clms Page number 23>
16. Dispositif selon l'une quelconque des revendications 9 à 15, caractérisé en ce qu'il est adapté à mettre en oeuvre un langage de balisage qui est un langage XML, et à mettre en oeuvre un langage de schéma associé qui est un langage de schéma XML.
17. Dispositif selon l'une quelconque des revendications 9 à 13, caractérisé en ce que les moyens de définition sont incorporés dans : - un microprocesseur (100), - une mémoire morte (102) comportant un programme pour traiter les données, et - une mémoire vive (103) comportant des registres adaptés à enregistrer des variables modifiées au cours de l'exécution dudit programme.
18. Ordinateur caractérisé en ce qu'il comporte le dispositif selon l'une quelconque des revendications 9 à 13.
19. Ordinateur caractérisé en ce qu'il comporte le dispositif selon la revendication 14 ou 15.
20. Réseau de communication, caractérisé en ce qu'il comporte au moins un ordinateur selon la revendication 18 et un ordinateur selon la revendication 19.
21. Programme d'ordinateur sur un support d'informations, caractérisé en ce qu'il comporte des instructions de programme adaptées à la mise en oeuvre du procédé selon l'une quelconque des revendications 1 à 8, lorsque ce programme d'ordinateur est chargé et exécuté dans un système informatique.
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0108771A FR2826748B1 (fr) | 2001-07-02 | 2001-07-02 | Description d'une interface applicable a un objet informatique |
| FR0108772A FR2826749B1 (fr) | 2001-07-02 | 2001-07-02 | Description d'une interface applicable a un objet informatique |
| JP2002185219A JP3768925B2 (ja) | 2001-07-02 | 2002-06-25 | スキーマ言語で記述した関数によりオブジェクトを操作する方法、装置およびプログラム |
| US10/186,753 US7299449B2 (en) | 2001-07-02 | 2002-07-02 | Description of an interface applicable to a computer object |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0108771A FR2826748B1 (fr) | 2001-07-02 | 2001-07-02 | Description d'une interface applicable a un objet informatique |
| FR0108772A FR2826749B1 (fr) | 2001-07-02 | 2001-07-02 | Description d'une interface applicable a un objet informatique |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2826748A1 true FR2826748A1 (fr) | 2003-01-03 |
| FR2826748B1 FR2826748B1 (fr) | 2003-11-28 |
Family
ID=26213079
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0108771A Expired - Fee Related FR2826748B1 (fr) | 2001-07-02 | 2001-07-02 | Description d'une interface applicable a un objet informatique |
| FR0108772A Expired - Fee Related FR2826749B1 (fr) | 2001-07-02 | 2001-07-02 | Description d'une interface applicable a un objet informatique |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0108772A Expired - Fee Related FR2826749B1 (fr) | 2001-07-02 | 2001-07-02 | Description d'une interface applicable a un objet informatique |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US7299449B2 (fr) |
| JP (1) | JP3768925B2 (fr) |
| FR (2) | FR2826748B1 (fr) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2923037A1 (fr) * | 2007-10-26 | 2009-05-01 | France Telecom | Procede de realisation d'un appel de procedure et produit programme d'ordinateur correspondant. |
Families Citing this family (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8600783B2 (en) | 2000-08-18 | 2013-12-03 | The Crawford Group, Inc. | Business to business computer system for communicating and processing rental car reservations using web services |
| US7181747B2 (en) | 2001-10-01 | 2007-02-20 | Canon Kabushiki Kaisha | Method and device for executing a function with selection and sending of multiple results in a client-server environment |
| US6631298B1 (en) * | 2002-07-31 | 2003-10-07 | Smar Research Corporation | System and method for providing information in a particular format |
| US7110843B2 (en) | 2003-02-24 | 2006-09-19 | Smar Research Corporation | Arrangements and methods for monitoring processes and devices using a web service |
| US7389498B2 (en) * | 2003-03-25 | 2008-06-17 | Microsoft Corporation | Core object-oriented type system for semi-structured data |
| US7266812B2 (en) * | 2003-04-15 | 2007-09-04 | Smar Research Corporation | Arrangements, storage mediums and methods for transmitting a non-proprietary language device description file associated with a field device using a web service |
| US20040230582A1 (en) * | 2003-05-13 | 2004-11-18 | Pagnano Marco Aurelio De Oliveira | Arrangement, storage medium and method for providing information which is obtained via a device type manager, and transmitted in an extensible mark-up language format or a hypertext mark-up language format |
| US7720969B2 (en) * | 2003-07-23 | 2010-05-18 | Canon Kabushiki Kaisha | Description document for a service offered by a server in a communication network and method of validating a multimedia document |
| US7512125B2 (en) * | 2003-12-19 | 2009-03-31 | Solace Systems, Inc. | Coding of routing protocol messages in markup language |
| US10366352B2 (en) * | 2006-10-06 | 2019-07-30 | The Crawford Group, Inc. | Method and system for communicating vehicle repair information to a business-to-business rental vehicle reservation management computer system |
| US8160906B2 (en) | 2006-12-12 | 2012-04-17 | The Crawford Group, Inc. | System and method for improved rental vehicle reservation management |
| WO2009015288A1 (fr) | 2007-07-25 | 2009-01-29 | The Crawford Group, Inc. | Système et procédé pour attribuer des coûts de location de véhicule de remplacement en utilisant une banque virtuelle de crédits d'établissement de réparation |
| US8572594B2 (en) * | 2010-12-22 | 2013-10-29 | Microsoft Corporation | Invasion analysis to identify open types |
| US11704370B2 (en) | 2018-04-20 | 2023-07-18 | Microsoft Technology Licensing, Llc | Framework for managing features across environments |
| US12012110B1 (en) | 2023-10-20 | 2024-06-18 | Crawford Group, Inc. | Systems and methods for intelligently transforming data to generate improved output data using a probabilistic multi-application network |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1065592A1 (fr) * | 1999-06-25 | 2001-01-03 | Canon Research Centre France S.A. | Gestion partagée d'objets dans un réseau de communication |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6125391A (en) * | 1998-10-16 | 2000-09-26 | Commerce One, Inc. | Market makers using documents for commerce in trading partner networks |
| US20020049790A1 (en) * | 2000-08-08 | 2002-04-25 | Ricker Jeffrey M | Data interchange format transformation method and data dictionary used therefor |
| US6990654B2 (en) * | 2000-09-14 | 2006-01-24 | Bea Systems, Inc. | XML-based graphical user interface application development toolkit |
-
2001
- 2001-07-02 FR FR0108771A patent/FR2826748B1/fr not_active Expired - Fee Related
- 2001-07-02 FR FR0108772A patent/FR2826749B1/fr not_active Expired - Fee Related
-
2002
- 2002-06-25 JP JP2002185219A patent/JP3768925B2/ja not_active Expired - Fee Related
- 2002-07-02 US US10/186,753 patent/US7299449B2/en not_active Expired - Fee Related
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1065592A1 (fr) * | 1999-06-25 | 2001-01-03 | Canon Research Centre France S.A. | Gestion partagée d'objets dans un réseau de communication |
Non-Patent Citations (4)
| Title |
|---|
| CHRISTENSEN E, CURBERA F, MEREDITH G, WEERAWARANA S: "Web Services Description Language (WSDL) 1.1", W3C TECHNICAL RECOMMENDATION, 15 March 2001 (2001-03-15), XP002203550, Retrieved from the Internet <URL:http://www.w3.org/TR/wsdl> [retrieved on 20020626] * |
| JACOBSEN H -A ET AL: "Modeling interface definition language extensions", PROCEEDINGS 37TH INTERNATIONAL CONFERENCE ON TECHNOLOGY OF OBJECT-ORIENTED LANGUAGES AND SYSTEMS. TOOLS-PACIFIC 2000, PROCEEDINGS 37TH INTERNATIONAL CONFERENCE ON TECHNOLOGY OF OBJECT-ORIENTED LANGUAGES AND SYSTEMS. TOOLS-PACIFIC 2000, SYDNEY, NSW, A, 2000, Los Alamitos, CA, USA, IEEE Comput. Soc, USA, pages 242 - 251, XP002203549, ISBN: 0-7695-0918-5 * |
| KYLLINGSTAD R: "XML-Schema based semantic representation: design, implementation and usage", DIPLOMA THESIS - COMPUTER SYSTEMS INSTITUTE, DEPARTMENT OF COMPUTER SCIENCE, ETH, 30 May 2001 (2001-05-30), Zürich, XP002203548, Retrieved from the Internet <URL:http://www.cs.inf.ethz.ch/~zueff/USR/Project/Rene_Diploma.pdf> [retrieved on 20020626] * |
| MISCHKINSKY J, HURLEY O, HENNING M, THOMPSON P: "Simple CORBA Object Access Protocol (SCOAP): A Discussion Paper - Presentation Slides", OMG TECHNICAL COMMITTE DOCUMENT - ORBOS/00-09-04, 18 September 2000 (2000-09-18), Burlingame, CA, XP002203547, Retrieved from the Internet <URL:http://www.omg.org/docs/orbos/00-09-04.pdf> [retrieved on 20020626] * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2923037A1 (fr) * | 2007-10-26 | 2009-05-01 | France Telecom | Procede de realisation d'un appel de procedure et produit programme d'ordinateur correspondant. |
Also Published As
| Publication number | Publication date |
|---|---|
| FR2826749A1 (fr) | 2003-01-03 |
| JP3768925B2 (ja) | 2006-04-19 |
| JP2003076556A (ja) | 2003-03-14 |
| US7299449B2 (en) | 2007-11-20 |
| FR2826748B1 (fr) | 2003-11-28 |
| FR2826749B1 (fr) | 2005-09-09 |
| US20030050942A1 (en) | 2003-03-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Beazley et al. | Python cookbook: Recipes for mastering Python 3 | |
| FR2826748A1 (fr) | Description d'une interface applicable a un objet informatique | |
| US7490167B2 (en) | System and method for platform and language-independent development and delivery of page-based content | |
| FR2909198A1 (fr) | Procede et disositif de filtrage d'elements d'un document structure a partir d'une expression. | |
| EP1356595A2 (fr) | Procede de compression/decompression d'un document structure | |
| WO2006136565A1 (fr) | Procede de traitement de donnees compatible avec un formalisme de modelisation d'objets | |
| FR2906383A1 (fr) | Referentiel semantique de services web et procede utilisant ce referentiel | |
| US7302437B2 (en) | Methods, systems, and computer-readable media for a global video format schema defining metadata relating to video media | |
| FR2844370A1 (fr) | Document electronique de description d'un service informatique | |
| FR2907567A1 (fr) | Procede et dispositif de generation de motifs de reference a partir d'un document ecrit en langage de balisage et procedes et dispositifs de codage et de decodage associes. | |
| WO2001044887A2 (fr) | Procede de commercialisation de biens ou de services par des moyens electroniques sur des reseaux du type internet | |
| WO2008095800A1 (fr) | Procede de transmission d'au moins un contenu representatif d'un service, depuis un serveur vers un terminal, dispositif et produit programme d'ordinateur correspondants | |
| EP1260911A1 (fr) | Structure de données interne pour application destinée à s'interfacer avec une interface pour un document de type HTML ou XML | |
| FR2853972A1 (fr) | Procede de generation d'une interface de programme d'application pour des informations basees sur un cadre de description de ressources (rdf) | |
| FR2911200A1 (fr) | Procede et dispositif de traitement de documents a partir de schemas enrichis et procede et dispositif de decodage correspondants | |
| FR2816793A1 (fr) | Dispositif de traitement d'information multimedia | |
| EP1872279A1 (fr) | Procede de traitement d'une structure de donnees arborescente | |
| CN115774767B (zh) | 一种地理信息元数据处理方法及装置 | |
| Sehring | On the Generation of External Representations of Semantically Rich Content for API-Driven Document Delivery in the Headless Approach | |
| EP1811373A1 (fr) | Procédé de composition automatique de services web, produit de programme d'ordinateur et système informatique de mise en oeuvre de ce procédé | |
| EP1713243A1 (fr) | Procédé et système de génération automatique de composants logiciels pour la conception de services vocaux | |
| Janson | THE “DENVER MULTIMEDIA DATABASE”: A FORENSIC DATABASE FOR DIGITAL AUDIO, VIDEO, AND IMAGE MEDIA | |
| FR2795535A1 (fr) | Procede d'execution a distance d'une fonction sur un objet informatique dans un reseau de communication | |
| FR2795536A1 (fr) | Procede de traduction, de transfert et de mise a jour d'un objet informatique sur un reseau de communication informatique | |
| FR2914453A1 (fr) | Procedes et dispositifs de gestion de version de traitements de documents de type xml |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| ST | Notification of lapse |
Effective date: 20140331 |