EP1285361A1 - Systeme de publication multi-terminal et procede de mise en oeuvre correspondant - Google Patents

Systeme de publication multi-terminal et procede de mise en oeuvre correspondant

Info

Publication number
EP1285361A1
EP1285361A1 EP01936548A EP01936548A EP1285361A1 EP 1285361 A1 EP1285361 A1 EP 1285361A1 EP 01936548 A EP01936548 A EP 01936548A EP 01936548 A EP01936548 A EP 01936548A EP 1285361 A1 EP1285361 A1 EP 1285361A1
Authority
EP
European Patent Office
Prior art keywords
type
webbike
making
instruction
language
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.)
Withdrawn
Application number
EP01936548A
Other languages
German (de)
English (en)
Inventor
François ZISERMAN
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Wokup!SA
Original Assignee
Wokup!SA
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Wokup!SA filed Critical Wokup!SA
Publication of EP1285361A1 publication Critical patent/EP1285361A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
    • G06F16/986—Document structures and storage, e.g. HTML extensions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/258—Data format conversion from or to a database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/252—Integrating or interfacing systems involving database management systems between a Database Management System and a front-end application

Definitions

  • Multi - terminal publication system and corresponding implementation method.
  • the field of the invention is that of communication networks, which are accessed by terminals of different types. More specifically, the invention relates to a multi-terminal publication system, making it possible to publish the same document in different formats, so as to make it searchable from different types of communication terminals.
  • the invention applies in particular, but not exclusively, to the publication of information available on the global Internet network, or on any other internet type network, to terminals of various types, such as WAP type terminals (in "Wireless Application Protocol"), PDA type terminals (in English “Personal Digital Assistant”), Minitel type terminals, etc.
  • WAP type terminals in "Wireless Application Protocol”
  • PDA type terminals in English “Personal Digital Assistant”
  • Minitel type terminals etc.
  • the invention also applies, for example, to the publication of information contained in databases, files, or modules of the java type.
  • a first solution making it possible to make a service accessible to different types of terminals, consists in developing as many versions of this service as there are types of terminals which can access it. Implementation of such a solution guarantees a presentation of the quality service, adapted to the type of terminal used.
  • a disadvantage of this technique of the prior art is that it requires significant development time.
  • Another drawback of this technique of the prior art is that maintenance work is made difficult by the high number of versions of the service, which increases with the number of types of target terminals.
  • Another solution consists in carrying out an automatic conversion of the content of the services.
  • a set of generic rules is used which make it possible, for example, to transform the HTML pages of websites into other formats, such as the WML format, or the "HTML light" format.
  • Such generic rules can for example consist in degrading the quality of images, transforming HTML tags, etc.
  • a drawback of this technique of the prior art is that the conversion tools used do not have the knowledge of the service processed, and the result obtained is therefore of poor quality. In particular, these tools are not capable of identifying the relevant information within the service to be converted.
  • Another disadvantage of this technique of the prior art is that it is only suitable for the WML language, and therefore for the automatic conversion of a website, so as to make it accessible to mobile phones.
  • Another drawback of such a technique is that it does not allow the information contained in the website to be filtered, depending on the recipient terminal.
  • the "WebSphere Transcoding Publisher” module implements a transformation engine allowing, using a set of generic and specific rules, a direct transformation of the raw data extracted from information sources in HTML or XML formats, in XML format data, accessible by a plurality of terminals of different types.
  • Such a module acts as a proxy.
  • a disadvantage of this technique of the prior art is that the processor implemented within such a module has no intelligence and is therefore not capable of identifying the relevant information within the raw data to be transformed.
  • Oracle's "Portai - To - Go” solution consists of a data extractor, composed of a plurality of extraction modules, and a transformation engine.
  • Each extraction module is an API (in English "Application Program Interface") which allows respectively to extract raw data in HTML, XML format, or from databases for example, and convert them to XML format.
  • an extractor performs a search for regular expressions, from a registered library, that is to say it implements a search for patterns (in English "patterns”), for example at within a given web page, based on a predetermined grammar.
  • the converted data is then transformed so as to be accessible to different types of destination terminals.
  • the "Portai - To - Go" transformation engine includes as many transformation modules as there are types of terminal - destination: each of these modules allows the presentation of the converted data in XML format to be adapted to the type of terminal - destination.
  • This "Portai - To - Go” technique also has the disadvantage of providing the destination terminal with a presentation of the transformed data, which is dependent on the presentation of the original raw data.
  • the "Portai -To -Go" technique also has the disadvantage of not making it possible to respect the tree structure of the Web page from which the information constituting the objects is extracted. Indeed, the search for regular expressions implemented does not take into account the tree structure of the page analyzed. We can then extract from the page a pattern belonging, in part, to a first branch, and, in part, to a second branch of the tree structure of the page. Thus, after extracting the raw data contained in a web page, we lose all notion of navigation within the objects contained in the analyzed page.
  • the invention particularly aims to overcome these drawbacks of the prior art.
  • an objective of the invention is to provide a multi-terminal publication system, making it possible to publish the same document in different formats, so as to make it searchable from different types of communication terminals.
  • Another objective of the invention is to implement a multi-terminal publication system which is inexpensive and not very complex to implement.
  • the invention also aims to implement a multi-terminal publication system, which adapts to any type of data source as well as to any type of consultation terminal.
  • the invention also aims to provide a scalable multi-terminal publication system, making it easy to adapt to the evolution of sources of information and documents.
  • the invention also aims to provide a multi-terminal publication system suitable for all light terminals.
  • such a system comprises: at least one object creation module, making it possible to provide at least one function for creating objects from raw data extracted from said at least one source of information and / or generated by said at least one object creation module; a response generation module in a generic presentation format, in response to a request made by a terminal and relating to a given application, said application being defined, within said response generation module, by a plurality of contexts and a navigation policy among said contexts, each context comprising at least one action and / or at least one object, created by said at least one module for creating objects, said response resulting from navigation according to said navigation policy within said plurality of contexts; a presentation module, making it possible to transform said response in a generic presentation format into a response in a presentation format specific to the type of said terminal having formulated said request.
  • the invention is based on a completely new and inventive approach to multi-terminal publication, making it possible to make a document accessible to a plurality of terminals of different types. Indeed, it is based in particular on the new concept of separation of information and the presentation of information.
  • the invention is also based on a new concept of navigation within a set of contexts, in which actions and / or objects created by the multi-terminal publication system are grouped.
  • a response from such a system according to the invention to the request from a communication terminal is thus developed by a generic navigation technique, independent of the type of consultation terminal, which makes it possible to construct a tree structure of objects, created in whole or in part from the data contained in sites
  • said response in a generic presentation format is an XML type or SGML type tree.
  • the XML language in English “Extended Markup Language”
  • SGML in English “Standard Generalized Markup Language”
  • SGML in English “Standard Generalized Markup Language”
  • such a system further comprises an interfacing module making it possible to intercept and analyze said request formulated by a terminal, so as to: identify the type of said terminal; create a new request, in a generic request format, intended for said response generation module.
  • the system according to the invention can return a response, the content and presentation of which are perfectly suited to the terminal that issued the request.
  • each object comprises at least one member relating to the structure of said object and at least one constructor, said at least one constructor enabling said at least one module for creating objects to inform the content of said at least one member.
  • a "film” object consists of three members, namely a first member “film title”, a second member “film summary”, and a third member "director”.
  • said at least one object creation module belongs to the group comprising: - an object creation module, called a Webbike module, making it possible to provide at least one function for creating objects from raw data extracted from at least one data source containing at least one document expressed in a "markup" type language; an object creation module, making it possible to provide at least one function for creating objects from raw data extracted from at least one database of the SQL type; (in English "Structured Query
  • Such a system according to the invention thus makes it possible to publish on a terminal having issued a request, data coming from multiple sources of information, and in particular from websites, databases, XML-type files, as well as data generated or extracted by implementing a module java type.
  • an object is entirely created from data extracted from a Web site. It is also conceivable that certain members of an object are informed from data extracted from a database, and that, for example, all of the other members of the object are informed from data generated by a java type module.
  • the objects created by the object creation modules are preferably described using a language of the SIDL type (in English "Service Interface Definition Language”), but any other type of language adapted to the invention can also be used.
  • said presentation module is constructed using a language of the XSL type (in English "Extended Stylesheet Language”).
  • said at least one application is composed, according to a first specific language, of a service container, describing said service, and of at least one context container , each corresponding to a stage of said navigation.
  • Each application is thus composed of a service container and one or more context containers.
  • the service container is used to describe the instructions to be executed when the application is launched. It also makes it possible to declare entities (for example variables or procedures) usable in all the application considered.
  • the context container makes it possible to describe a context, that is to say a stage of navigation within the application considered.
  • the invention implements instructions allowing, during a session, to change service.
  • the transmission of a request and the visualization of its response, during a single session can therefore be associated with a plurality of services.
  • a container is composed of at least one component, making it possible to group together at least one instruction.
  • a system according to the invention implements six types of components: components of the "entry point" type, making it possible to describe a first plurality of operations that said response generation module must perform at launch.
  • components of the “attributes” type making it possible to describe a plurality of variables usable in said current container
  • components of the "method” type making it possible to group a plurality of said at least one instruction within a procedure
  • components of the "imports” type making it possible to describe said at least one object necessary for said response generation module, to generate said response to said request relating to a given application
  • components of the “processing” type making it possible to describe a second plurality of operations that said response generation module must perform in response to an action performed by a terminal
  • components of the “content” type making it possible to describe said information supplied to a terminal within said response and / or to describe said at least one action that said terminal can perform at a stage of said given navigation. Examples of components of the types set out above are presented in Annex 1. This appendix, as well as the following, is of course part of the present description in its own right.
  • an entry point component is characterized by its name, possibly parameters, and the set of instructions that the response generation module must perform when launching the execution of the container. service or the context container to which such an "entry point" type component belongs.
  • An attribute type component is used to describe variables that can be used in all the components of the current container. Thus, if the attribute component belongs to a service container, the variables that it declares are accessible from all the contexts of the application considered.
  • the set of instructions of a content type component allow, when executed, to generate an XML tree containing all the information that the multi-terminal publishing system according to the invention offers to the terminal having issued the request considered.
  • such a system implements the following four types of instructions: “content” type instructions, making it possible to generate part of said response in a generic presentation format; - “variable manipulation” type instructions, making it possible to declare and / or manipulate at least one variable; “navigation” type instructions, making it possible to change the current context and / or the current application; “use” type instructions, which can be used by instructions and / or components.
  • said “content” type instructions belong to the group comprising: a “content - literal” instruction, making it possible to describe a character string of said response in a generic format; - a "content - object” instruction, making it possible to describe an object; a “content - list” instruction, used to describe a list of objects; a “content - item” instruction, allowing to describe an element of a list; a “content - member” instruction, used to describe a member of an object; a “content - selection” instruction, making it possible to select an item from a list; a “content - selection - multiple” instruction, making it possible to select at least one item from a list; - a "content - entry” instruction, used to describe an item of type
  • the instruction "content - literal”, which makes it possible to describe a character string to be inserted in the XML tree constituting the response, is characterized by the character string to be inserted and the name of the node of the XML tree generated.
  • the "content - object” instruction makes it possible, for its part, to describe a SIDL object that the system according to the invention proposes to the terminal having sent the processed request.
  • Such an object can be referenced by its name in all the components of the context to which the component of the "content” type belongs.
  • the "content - object” In order for the "content” component which contains this instruction to be correctly executed, the "content - object” must be initialized before calling the instruction executing the "content” component.
  • said instructions of “variable manipulation” type belong to the group comprising: an "object” instruction, used to declare a type variable
  • object ; a “list” instruction, allowing to declare a “list” type variable; a “simple” instruction, making it possible to declare a variable of type “simple”, distinct from said type “object” and from said type “list”; a “create” instruction, making it possible to construct an object or a list of objects; an "establishment” instruction, making it possible to assign a value to a variable; - a “list - move” instruction, making it possible to move a current pointer from a list, by specifying a displacement step; a "list - move - to” instruction, making it possible to move a current pointer from a list, by specifying a new position of said pointer.
  • the MDSP language makes it possible to declare and manipulate variables, which can be used to store information or to transmit parameters.
  • the instruction "object” allows to declare a variable of type object.
  • This object can be referenced by name in all components of the current container. Before being referenced, it must be initialized using a predetermined instruction.
  • the "object" instruction is characterized by the name of the declared variable and by an SIDL class of the object.
  • variable of simple type that is to say a variable that can contain a character string, an integer or a float. It is characterized by the name of the variable and by the value that this variable possibly takes on initialization.
  • the "create” instruction is used to build an object or a list of SIDL objects declared in the current context or in the current service. It is characterized by the name of the variable to build, the SIDL constructor to use, and the values assigned to the constructor parameters. We present, in appendix 3, some examples of instructions of type "manipulation of variables".
  • said “navigation” type instructions belong to the group comprising: - a “change - context” instruction, making it possible to instantiate a new context; a "change - service” instruction, allowing to instantiate a new service; a "context - previous” instruction, allowing to return to the previous context in the current service; a "service - previous” instruction, making it possible to return to the previous context with the last context of said service.
  • a "context-previous" instruction makes it possible to return to a previous context in the current service.
  • the current context then becomes this context, in the state in which it was left the last time.
  • the presentation returned to the terminal that issued the request therefore corresponds to that described by the last component of the "content" type executed on this context.
  • said “use” type instructions belong to the group comprising: a “call” instruction, making it possible to call a “method” component in the current context or service; an "if” instruction, making it possible to establish a condition on a set of instructions; an “otherwise” instruction, following an “if” instruction and making it possible to establish a condition on a set of instructions; an “otherwise - if” instruction, following a "if” instruction and making it possible to establish at least one other condition on said set of instructions; an "execute - content” instruction, making it possible to generate a presentation of said information described in a "content”component; a "SIDL - import” instruction, used to specify an object to be used in the current service; - a "parameter - list” instruction, used to group parameter declarations; a "parameter” instruction, used to specify the value of a parameter; a “do” instruction, making
  • a "call” instruction makes it possible to call a method (that is to say a component of the "method” type) declared in the current context or in the current service. It is characterized by the name of the method called and by the values assigned to the parameters of the method.
  • An "execute - content” instruction is used to trigger the generation of the presentation of the information described by a content component. It is characterized by the name of the content whose presentation we want to generate and the name of the XSL model that we want to use, if we do not want to use that of the content.
  • said at least one object creation function further comprises a sub-function for comparing said at least one object to which said request relates with a list of objects previously at least partially created, so as not to put implements said at least one extraction sub-function only for the creation of objects not previously created and / or to complete objects previously partially created.
  • each extraction sub-function is composed, according to a second specific language, of at least one Webbike page comprising at least one Webbike node, and said at least one Webbike page is synchronized with at least a document expressed in a “markup” type language from at least one data source, said at least one document itself comprising at least one node of a “markup” type language, said synchronization allowing a Webbike node to position itself on a node of a "markup” type language in order to extract raw data therefrom with a view to said creation of objects.
  • the Webbike language makes it possible to create SIDL objects and to initialize the value of their attributes, from information contained in a data source of a "markup" type language
  • the Webbike language is used to describe a complete service. Consequently, a given Webbike page can contain the description of several documents expressed in a type of language. associated "markup", for example of several HTML pages whatever the address of the server which provides them.
  • Webbike module The principle of such a Webbike language is to tell the object creation module called Webbike module, how to search for information in HTML pages, or in XML documents, for example.
  • Webbike nodes also called Webbike tags
  • Synchronization allows the Webbike module to position itself on a node of a markup type language, and to extract information from it, such as the value of its attributes, for example, in order to assign them to the members of objects. SIDL.
  • said extraction sub-function on receipt of a request for at least one first object, also makes it possible to inform the content of at least one member of at least one second object, distinct from said at least one first object, when raw data making it possible to fill in said content are present within said document with which said at least one Webbike page is synchronized.
  • the object creation module accesses, for example, a web page, it creates, at least partially, all the objects capable of being created from the information contained in this web page.
  • the extraction sub-function therefore extracts all the raw data making it possible to inform the content of the members of objects, including objects on which the processed request does not relate.
  • the object creation module optimizes access to the data sources, by browsing and analyzing only once each of the web pages, or of the XML documents contained in the data sources. For example, the object creation module accesses a given Web page to create a "film” object: it then also extracts the raw data contained in the page and makes it possible to inform at least some of the members of the objects " director "and” film festival ".
  • Webbike nodes of synchronization type making it possible to search for a node of a "markup" type language or a "frame" of a node of a "markup” type language in said at least one document expressed in a "markup" type language, in order to position itself on said node of a "markup” type language or on said "frame”
  • structure type Webbike nodes making it possible to define at least one execution condition for said synchronization type Webbike nodes
  • - Webbike command type nodes making it possible to implement at least one predetermined operation after being positioned on said node of a "markup” type language or on said "frame”.
  • the set of Webbike nodes constitutes a Webbike instruction tree commanding an interpreter to allow "browsing" within the analyzed data source. Such navigation is triggered by the reception, by the Webbike module, of a request to create objects.
  • synchronization type nodes making it possible to synchronize on a node of a "markup" type language of the page or document analyzed by the object creation module.
  • This synchronization condition can notably consist in carrying out a search for regular expressions within the content of said node of a "markup" type language. It should be noted that such a search for regular expressions is also used, within a web page, in the multi-terminal publishing system "Portai - To - Go", but for a completely different purpose
  • Webbike nodes of the type allowing the definition of an extraction sub-function
  • Webbike tag Webbike nodes of the type allowing the indication of the object (s) used (s) in an extraction sub-function
  • tag implements
  • Webbike (action tag) - Webbike nodes of the type allowing the definition of a dynamic URL for an HTML page; (dynamic-url tag) of Webbike nodes of the type allowing to assign a value to a parameter; (param tag) Webbike nodes of the type allowing a sequence of at least one Webbike node to be repeated; (multiple tag) of Webbike nodes of the type allowing to include at least one command in a normally unauthorized location of a sequence of at least one Webbike node; (tag block) Webbike nodes of the type allowing to define at least two ways of synchronizing according to the content of a document; (tag switch) Webbike nodes of the type making it possible to conditionally interpret a sequence of at least one Webbike node.
  • said command type Webbike nodes belong to the group comprising: Webbike nodes of the type making it possible to define a block of at least one command associated with a node (Webbike tag) of the type allowing the definition of a sub-function extraction; (tag command) - Webbike nodes of the type allowing the extraction of the textual content of a node of a "markup" type language; (tag body) of Webbike nodes of the type allowing the extraction of at least one attribute of the node from a current "markup" type language; (tag attributes) of Webbike nodes of the type allowing to designate a constant value; (constant tag) of Webbike nodes of the type allowing to assure functions of transformation of information extracted from a file expressed according to a language of type "markup".
  • said at least one command, of a block defined by a Webbike node belongs to the group comprising: commands for creating objects; commands to modify at least one member of an object. There is thus, in particular, a command for creating a new object
  • SIDL a command for updating the members of a SIDL object, and a command for adding text to a member of a SIDL object.
  • Webbike page there are at least the following two types of Webbike page: static Webbike pages, analyzed at the launch of said extraction sub-function; dynamic Webbike pages, accessible from another Webbike page by a Webbike node of a particular type, known as a Webbike link.
  • static pages have a fixed URL, specified in a node
  • a dynamic page can define parameters allowing objects to be passed from page to page.
  • a parameter can be a simple object, such as a character string, or a SIDL object.
  • there is at least one specific synchronization type Webbike node making it possible to search for a node of a predetermined "markup" type language, in order to position itself on said node of a predetermined "markup” type language, and , in addition, a generic synchronization type Webbike node making it possible to search for a node of a language of type "markup" not - predetermined but specified in parameter, in order to position itself on said node of a language of type "markup" not - predetermined.
  • markup type languages such as XML, WML or HTML are too rich to be able to provide a Webbike synchronization node for each node of an existing markup type language.
  • a Webbike node of the generic synchronization type which makes it possible to synchronize on any node of a "markup" type language, provided that specify the name of the element on which we want to synchronize.
  • the synchronization type nodes take into account extraction conditions relating to attributes and / or textual content and / or at least one child node of a node of a markup type language. find. If several nested nodes meet the criteria established in the extraction conditions, the first node encountered is generally retained.
  • said Webbike module implements a cookie management function.
  • cookies sent by an HTTP server when retrieving an HTML page are stored at the Webbike module level. They are automatically returned by the Webbike module when it accesses pages that correspond to the domain of the cookie.
  • Some websites depend on the management of cookies, it is important to identify the resource that causes the emission of the cookie, in order to access it from the Webbike module at the appropriate time.
  • At least one of said first and second specific languages is constructed using a language of the XML type.
  • said "markup" type language belongs to the group comprising: XML type languages (in English “Extended Markup Language”); HTML-type languages (in English “HyperText Markup Language”); SGML type languages (in English “Standard Generalized Markup
  • the invention also relates to a method of implementing a system according to any one of claims 1 to 26, characterized in that it comprises the following steps: a terminal sends a request relating to a given application to said said system; to develop a response to said request, said response generation module sends a request for at least one object to said at least one object creation module, so as to inform the plurality of contexts of said application; said at least one object creation module creates said at least one object and sends it back to said response generation module; said response generation module generates a response in a generic presentation format, implementing said navigation according to said navigation policy within said plurality of contexts; said presentation module receives from said response generation module said response in a generic presentation format and transforms it into a response in a presentation format specific to the type of said terminal having formulated said request; - said system sends said response in a specific presentation format to said terminal.
  • FIG. 1 presents a block diagram of the different types of terminals that can benefit from a multi-terminal publication system according to the invention
  • FIG. 2 illustrates the general architecture of a multi-terminal publication system towards the terminals presented in FIG. 1
  • FIG. 3 presents a block diagram of the various modules implemented in a multi-terminal publication system according to the invention
  • FIG. 4 describes more precisely the architecture of the multi-terminal publishing system illustrated in FIG.
  • FIG. 5 presents the different steps implemented during the processing of a request sent by a client of the multi-terminal publishing system of FIG. 3.
  • the general principle of the invention is based on the implementation of a multi-terminal publication system, based on the processing of a generic service, regardless of its format in a data source and its final presentation in the terminal. target.
  • FIG. 1 a block diagram of the different types of terminals that can access a service, extracted for example from a website 1, from a multi-terminal publication system 2 according to the invention.
  • terminals of various types such as a terminal of PDA type (in English "Personal Digital Assistant") 3 or 4, a mobile telephone of WAP type (in English "Wireless Application Protocol”) 5, a fixed telephony terminal 6, a Minitel 7 type terminal, or any other type of terminal, and in particular the light terminals 8, 9 and 10.
  • FIG. 2 The general architecture of a multi-terminal publication system is presented in FIG. 2.
  • the terminals 3, 4 and 5, already illustrated in FIG. 1, and a terminal 20 of the personal computer type access via a protocol of the HTTP type to the data. 21 extracted and disseminated on the global Internet network or on any other internet-type network by the web server 22.
  • the WAP terminal 5 does not support the HTTP type protocol, a WAP gateway 23 is implemented, so as to provide an interface between the HTTP type protocol and the WTP type protocol used on the mobile network.
  • a WAP gateway 23 is implemented, so as to provide an interface between the HTTP type protocol and the WTP type protocol used on the mobile network.
  • the different modules implemented in a multi-terminal publishing system according to the invention in the particular case where the data sources implemented are websites composed of a or several HTML page (s).
  • Such a multi-terminal publication system is then composed of three main modules: a module 30 for creating objects; a response generation module 31 in a generic format, using the language called MDSP; - a presentation module 32.
  • the object creation module 30 implements a sub-function for extracting data contained in the HTML pages, by performing synchronization on the HTML nodes. It creates objects using the SIDL language
  • the response generation module 31 in a generic format implements a computer language based on an XML type language. It retrieves the SIDL objects created by the module 30 for creating objects
  • the presentation module 32 uses style sheets, specific to each type of consultation terminal, to format the data originating from the response generation module 31, that is to say the intermediate XML tree provided by the module referenced 31, in a format readable by the terminal - destination.
  • FIG. 4 of the architecture of the multi-terminal publishing system, the various modules of which are illustrated in FIG. 3.
  • Certain data, contained in a data source 40 are extracted by an object creation module 30, to inform the members of certain objects, necessary for the construction of a response to a consultation terminal 5.
  • the module 30 implements a specific language, which allows the creation of objects of type SID1 (in English "Service Interface Definition Language").
  • the SIDL objects are then transmitted to the response generation module 31 in a generic presentation format, which elaborates a response in the form of an XML type tree.
  • Such an XML tree is then processed by a presentation module, which implements a set of style sheets 32.
  • Each style sheet is associated with a type of consultation terminal, and makes it possible to define the presentation criteria specific to each type of terminal.
  • the presentation module uses a style sheet characteristic of the terminals of WAP type, a style sheet characteristic of Minitel type terminals, a style sheet characteristic of PAD type terminals, etc.
  • the presentation module 32 can then supply, to the terminal 5 having issued a request intended for the multi-terminal publication system ' according to the invention, a response whose content and presentation are adapted to the type of the consultation terminal 5 (here , a WAP terminal).
  • the modules 30 for creating objects, 31 for generating responses, and 32 for presentation therefore operate independently, on the one hand, of the nature of the data source 40, and on the other hand, of the type of consultation terminal. 5.
  • the modules 30 for creating objects, 31 for generating responses, and 32 for presentation therefore operate independently, on the one hand, of the nature of the data source 40, and on the other hand, of the type of consultation terminal. 5.
  • a client 50 having a terminal adapted to the multi-terminal publishing system according to the invention issues a request 51 for access to a set of information.
  • the client 50 may request access to a given website, or to a set of information contained in a particular database.
  • the client 50 can also request information that the multi-terminal publishing system according to the invention must, for example, partially extract from a website, partially extract from a database, and partially generate by implementing a java type module.
  • the client 50 wishes, for example, to know the list of cultural events which will take place in a given city in the coming months.
  • the multi-terminal publication system comprises, in addition to the modules presented in FIGS. 3 and 4, an interfacing module 59, making it possible to intercept and analyze the request 51.
  • the interfacing module 59 determines the type of terminal used by the client 50 to send the request 51, so that the multi-terminal publication system according to the invention can transmit to the client 50 a response whose content and presentation are adapted to the type of consultation terminal.
  • the interfacing module 59 then transmits its request to the response generation module in a generic format 31, during a step referenced 52.
  • the response generation module 31 transmits to its turn a request to the set of object creation modules 30, so as to require the creation of the objects necessary for the construction of a response to the client 50.
  • the set of object creation modules 30 interrogates a set of data sources, in order to extract the information requested by the response generation module 31.
  • a java type module 302 generates certain SIDL objects
  • an object creation module 301 called a Webbike
  • an object creation module 302 creates SIDL objects from the raw data contained in one or more databases.
  • the set of object creation modules 30 transmits to the response generation module in a generic format 31 the SIDL objects created in response to the request 53, as well as necessary SIDL objects when generating a response to the request 51 from the client 50, previously created by all of the modules for creating objects 30.
  • the set of object creation modules 30 transmits to the response generation module 31 the objects already created previously, for example by extraction from a website and / or from a database and / or of a java module.
  • the set of object creation modules 30 upon receipt of a request 53, implements a comparison of the objects necessary for the response generation module 31 with a list of previously created objects, so to implement the functions of extraction or generation of objects only for objects not previously created.
  • the response generation module in a generic format 31 then implements navigation within the plurality of contexts relating to the service required by the client 50 during step 51. Such navigation within the contexts, in which the SIDL objects provided by the object creation modules 30 are grouped together, allows the response generation module in a generic format 31 to develop, during a step referenced 55, an XML type tree.
  • the presentation module 32 then processes this XML intermediate tree, so as to present the response sent to the client 50 in a format adapted to the type of consultation terminal.
  • the presentation module 32 uses a set of style sheets presented in FIG. 4, and grouping together the presentation characteristics specific to each type of consultation terminal.
  • the presentation module 32 sends the response, in a presentation format specific to the type of terminal having formulated the request 51, to the response generation module 31.
  • the module 31 then returns the final response to the interfacing module 59 during a step referenced 57.
  • the final response in a presentation format adapted to the type of terminal used by the client 50, is then forwarded to the consultation terminal, during a step referenced 58.
  • Webbike nodes of the type making it possible to conditionally interpret a sequence of at least one Webbike node:
  • Parameter name of the request (parameter of an SIDL Object constructor) - -> ⁇ ! - - list of parameters to pass to the CGI (list of ⁇ url-param>).
  • CGI list of ⁇ url-param>.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention concerne un système de publication multi-terminal, du type offrant un accès à au moins une application correspondant à un service, permettant de fournir à une pluralité de terminaux, selon au moins deux types de terminal distincts, des informations contenues dans au moins une source d'informations. Selon l'invention, un tel système comprend : au moins un module (30, 301, 302, 303) de création d'objets à partir de données brutes ; un module (31) de génération de réponse sous un format de présentation générique, en réponse à une requête (51) formulée par un terminal et relative à une application donnée ; un module (32) de présentation, permettant de transformer ladite réponse sous un format de présentation générique en une réponse sous un format de présentation spécifique au type dudit terminal ayant formulé ladite requête.

Description

Système de publication multi - terminal et procédé de mise en œuvre correspondant.
Le domaine de l'invention est celui des réseaux de communication, auxquels accèdent des terminaux de types différents. Plus précisément, l'invention concerne un système de publication multi - terminal, permettant de publier un même document sous différents formats, de façon à le rendre consultable à partir de différents types de terminaux de communication.
L'invention s'applique notamment, mais non exclusivement, à la publication d'informations disponibles sur le réseau mondial Internet, ou sur tout autre réseau de type internet, vers des terminaux de types variés, tels que des terminaux de type WAP (en anglais "Wireless Application Protocol"), des terminaux de type PDA (en anglais "Personal Digital Assistant"), des terminaux de type Minitel, etc. L'invention s'applique également, par exemple, à la publication d'informations contenues dans des bases de données, des fichiers, ou des modules de type java.
La publication de mêmes informations vers des terminaux de types différents est rendue difficile par la diversité des langages informatiques et des protocoles de communication, mis en œuvre dans chaque type de terminal. Ainsi, par exemple, les téléphones mobiles de type WAP (en anglais "Wireless Application Protocol") utilisent le langage WML (en anglais "Wireless Markup Language"), alors que des terminaux tels que les ordinateurs personnels mettent en œuvre un langage du type HTML (en anglais "Hypertext Markup Language"). À ce jour, plusieurs solutions ont été proposées au problème de la publication d'informations vers des terminaux de types différents.
Une première solution, permettant de rendre un service accessible à différents types de terminaux, consiste à développer autant de versions de ce service qu'il existe de types de terminaux pouvant y accéder. La mise en œuvre d'une telle solution garantit une présentation du service de qualité, adaptée au type de terminal utilisé.
Un inconvénient de cette technique de l'art antérieur est qu'elle nécessite un temps de développement important. Un autre inconvénient de cette technique de l'art antérieur est que les travaux de maintenance sont rendus difficiles par le nombre élevé de versions du service, qui s'accroît avec le nombre de types de terminaux cibles.
Dans le cas, par exemple, où un utilisateur souhaite accéder à un site Web à l'aide d'un téléphone mobile, il est nécessaire, selon cette première solution, de mettre en œuvre une passerelle de type WAP (en anglais "Wireless Application Protocol") entre le réseau de type internet et le réseau mobile, et de développer une nouvelle version du site Web, construit à partir d'un langage du type HTML (en anglais "Hypertext Markup Language"), qui soit adaptée au mobile, c'est-à- dire construite notamment à partir d'un langage du type WML (en anglais "Wireless Markup Language").
Une autre solution consiste à réaliser une conversion automatique du contenu des services. On utilise, dans ce dessein, un ensemble de règles génériques qui permettent, par exemple, de transformer les pages HTML des sites Web en d'autres formats, tels que le format WML, ou le format "HTML light". De telles règles génériques peuvent par exemple consister à dégrader la qualité des images, à transformer les tags HTML, etc.
La mise en œuvre d'une telle solution, proposée, par exemple, par HelpInHand ASA BabelServer (marque déposée), consiste à réaliser une republication de langage à langage, à l'aide d'un traducteur adapté. Selon cette technique, les adresses des localisateurs de ressources uniformes (URL, en anglais "Uniform Resource Locator") sont simplement filtrées par le traducteur.
Un inconvénient de cette technique de l'art antérieur est que les outils de conversion mis en œuvre n'ont pas la connaissance du service traité, et le résultat obtenu est donc de mauvaise qualité. Notamment, ces outils ne sont pas capables d'identifier les informations pertinentes au sein du service à convertir. Un autre inconvénient de cette technique de l'art antérieur est qu'elle est uniquement adaptée au langage WML, et donc à la conversion automatique d'un site Web, de manière à le rendre accessible aux téléphones mobiles.
Une telle technique a encore pour inconvénient de ne pas permettre de filtrer les informations contenues dans le site Web, en fonction du terminal destinataire.
Encore un autre inconvénient de cette technique de l'art antérieur est qu'elle ne permet pas de mettre en ligne un système de paiement adapté, permettant notamment aux utilisateurs de terminaux de type WAP ou PAD par exemple, d'accéder aux services payants du réseau Internet.
D'autres solutions, dites de republication par transformation prédéfinie, ont été proposées, notamment dans les serveurs "Portai To Go" d'Oracle et "WebSphere Transcoding Publisher" d'IBM (marques déposées).
Ainsi, le module "WebSphere Transcoding Publisher" met en œuvre un moteur de transformation permettant, à l'aide d'un ensemble de règles génériques et spécifiques, une transformation directe des données brutes extraites de sources d'informations aux formats HTML ou XML, en données au format XML, accessibles par une pluralité de terminaux de types différents. Un tel module agit comme un proxy. Un inconvénient de cette technique de l'art antérieur est que le processeur mis en œuvre au sein d'un tel module ne possède aucune intelligence et n'est donc pas capable d'identifier les informations pertinentes au sein des données brutes à transformer.
Un autre inconvénient de cette technique de l'art antérieur est que la présentation des données transformées est directement liée à la présentation des données brutes avant transformation, quel que soit le type de terminal utilisé. Notamment, dans le cas où un utilisateur souhaite accéder à un site Web à l'aide d'un téléphone mobile, la mise en œuvre du module "WebSphere Transcoding Publisher" contraint l'utilisateur à adopter une navigation, au sein du site transformé, identique à celle du site Web d'origine. La solution "Portai - To - Go" d'Oracle consiste en un extracteur de données, composé d'une pluralité de modules d'extraction, et en un moteur de transformation. Chaque module d'extraction est une API (en anglais "Application Program Interface", interface de programme d'application) qui permet respectivement d'extraire des données brutes au format HTML, XML, ou issues de bases de données par exemple, et de les convertir au format XML. Dans ce dessein, un extracteur effectue une recherche d'expressions régulières, à partir d'un librairie enregistrée, c'est-à-dire qu'il met en œuvre une recherche de motifs (en anglais "patterns"), par exemple au sein d'une page Web donnée, en fonction d'une grammaire prédéterminée.
Les données converties sont ensuite transformées, de façon à être accessibles à différents types de terminaux - destination. Le moteur de transformation "Portai - To - Go" comprend autant de modules de transformation que de types de terminaux - destination : chacun de ces modules permet d'adapter la présentation des données converties au format XML au type de terminal - destination.
Un inconvénient de cette technique de l'art antérieur est qu'elle est complexe à mettre en œuvre.
Un autre inconvénient de cette technique de l'art antérieur est qu'elle nécessite un temps de développement élevé, en raison du grand nombre de langages (en nombre égal au nombre de types de terminaux - destination) qu'il est nécessaire de mettre en œuvre dans le moteur de transformation.
Cette technique "Portai - To - Go" a encore pour inconvénient de proposer au terminal - destination une présentation des données transformées, qui est dépendante de la présentation des données brutes d'origine.
Encore un autre inconvénient de cette technique de l'art antérieur est que l'extracteur mis en œuvre ne permet pas un suivi automatique d'éventuels liens entre différentes pages Web. Notamment, si, au sein d'une page Web, un tel extracteur identifie une adresse URL (en anglais "Uniform Resource Locator") renvoyant vers une autre page Web, il ne demande pas à y accéder pour en extraire les données qu'elle contient.
La technique " Portai -To -Go" a encore pour inconvénient de ne pas permettre de respecter l'arborescence de la page Web de laquelle sont extraites les informations constitutives des objets. En effet, la recherche d'expressions régulières mise en œuvre ne tient pas compte de la structure arborescente de la page analysée. On peut alors extraire de la page un motif appartenant, en partie, à une première branche, et, en partie, à une deuxième branche de la structure arborescente de la page. Ainsi, après extraction des données brutes contenues dans une page Web, on perd toute notion de navigation au sein des objets contenus dans la page analysée.
L'invention a notamment pour objectif de pallier ces inconvénients de l'art antérieur.
Plus précisément, un objectif de l'invention est de fournir un système de publication multi - terminal, permettant de publier un même document sous différents formats, de façon à le rendre consultable à partir de différents types de terminaux de communication.
Un autre objectif de l'invention est de mettre en œuvre un système de publication multi - terminal qui soit peu coûteux, et peu complexe à mettre en œuvre.
L'invention a également pour objectif de mettre en œuvre un système de publication multi-terminal, qui s'adapte à tout type de source de données ainsi qu'à tout type de terminal de consultation.
L'invention a encore pour objectif de fournir un système de publication multi - terminal évolutif, permettant de s'adapter facilement à l'évolution des sources d'informations et de documents.
L'invention a également pour objectif de mettre en œuvre un système de publication multi - terminal, dans lequel les concepts de données et de présentation des données sont indépendants. Un autre objectif de l'invention est de mettre en œuvre un système de publication multi - terminal permettant de filtrer les informations des sources de données en fonction du terminal, ou du type de terminal, auquel elles sont destinées. L'invention a encore pour objectif de fournir un système de publication multi - terminal présentant une indépendance totale de la source d'informations et du terminal - destination, c'est - à - dire dans lequel les traitements mis en œuvre ne dépendent ni de la nature des informations extraites des sources de données, ni du type de terminal auquel elles sont destinées. Encore un autre objectif de l'invention est de mettre en œuvre un système de publication multi - terminal, dans lequel le contenu et la présentation des informations proposées au terminal - destination sont parfaitement adaptés au type de terminal - destination.
L'invention a encore pour objectif de fournir un système de publication multi - terminal adapté à tous les terminaux légers.
Ces objectifs, ainsi que d'autres qui apparaîtront par la suite sont atteints selon l'invention, à l'aide d'un système de publication multi - terminal, du type offrant un accès à au moins une application correspondant à un service, permettant de fournir à une pluralité de terminaux, selon au moins deux types de terminal distincts, des informations contenues dans au moins une source d'informations.
Selon l'invention, un tel système comprend : au moins un module de création d'objets, permettant de fournir au moins une fonction de création d'objets à partir de données brutes extraites de ladite au moins une source d'informations et/ou générées par ledit au moins un module de création d'objets ; un module de génération de réponse sous un format de présentation générique, en réponse à une requête formulée par un terminal et relative à une application donnée, ladite application étant définie, au sein dudit module de génération de réponse, par une pluralité de contextes et une politique de navigation parmi lesdits contextes, chaque contexte comprenant au moins une action et/ou au moins un objet, créé par ledit au moins un module de création d'objets, ladite réponse résultant d'une navigation selon ladite politique de navigation au sein de ladite pluralité de contextes ; un module de présentation, permettant de transformer ladite réponse sous un format de présentation générique en une réponse sous un format de présentation spécifique au type dudit terminal ayant formulé ladite requête.
Ainsi, l'invention repose sur une approche tout à fait nouvelle et inventive de la publication multi - terminal, permettant de rendre un document accessible à une pluralité de terminaux de types différents. En effet, elle repose notamment sur le concept nouveau de séparation de l'information et de la présentation de l'information. L'invention repose également sur un nouveau concept de navigation au sein d'un ensemble de contextes, dans lesquels sont regroupés des actions et/ou des objets créés par le système de publication multi - terminal. Une réponse d'un tel système selon l'invention à la requête d'un terminal de communication est ainsi élaborée par une technique générique de navigation, indépendante du type de terminal de consultation, qui permet de construire une structure arborescente d'objets, créés en tout ou en partie à partir des données contenues dans des sites
Web, des bases de données, des fichiers, ou des modules java par exemple. Avantageusement, ladite réponse sous un format de présentation générique est un arbre de type XML ou de type SGML.
En effet, le langage XML (en anglais "Extended Markup Language"), qui est un langage extrait du langage SGML (en anglais "Standard Generalized Markup Language"), est un langage générique particulièrement adapté à la publication et à l'échange de données.
Selon une caractéristique avantageuse de l'invention, un tel système comprend en outre un module d'interfaçage permettant d'intercepter et d'analyser ladite requête formulée par un terminal, de manière à : identifier le type dudit terminal ; créer une nouvelle requête, sous un format de requête générique, destinée audit module de génération de réponse.
Ainsi, le type de terminal de consultation étant identifié, le système selon l'invention peut renvoyer une réponse, dont le contenu et la présentation sont parfaitement adaptés au terminal ayant émis la requête.
Selon une technique avantageuse, chaque objet comprend au moins un membre relatif à la structure dudit objet et au moins un constructeur, ledit au moins un constructeur permettant audit au moins un module de création d'objets de renseigner le contenu dudit au moins un membre. On peut par exemple imaginer qu'un objet "film" soit constitué de trois membres, à savoir un premier membre "titre du film", un second membre "résumé du film", et un troisième membre "metteur en scène".
Dans un mode de réalisation avantageux de l'invention, ledit au moins un module de création d'objets appartient au groupe comprenant: - un module de création d'objets, appelé module Webbike, permettant de fournir au moins une fonction de création d'objets à partir de données brutes extraites d'au moins une source de données contenant au moins un document exprimé selon un langage de type "markup" ; un module de création d'objets, permettant de fournir au moins une fonction de création d'objets à partir de données brutes extraites d'au moins une base de données du type SQL ; (en anglais "Structured Query
Language", langage d'interrogation structuré) un module de création d'objets, construit à partir d'un langage du type java, permettant de fournir au moins une fonction de création d'objets à partir de données brutes générées par ledit module de création d'objets et/ou extraites d'au moins une source d'informations prédéterminées.
Un tel système selon l'invention permet ainsi de publier sur un terminal ayant émis une requête, des données provenant de sources d'informations multiples, et notamment de sites Web, de bases de données, de fichiers du type XML, ainsi que des données générées ou extraites en mettant en œuvre un module de type java. On peut envisager qu'un objet soit entièrement créé à partir de données extraites d'un site Web. On peut aussi envisager que certains membres d'un objet soient renseignés à partir de données extraites d'une base de données, et que, par exemple, l'ensemble des autres membres de l'objet soient renseignés à partir de données générées par un module de type java.
Les objets créés par les modules de création d'objets sont préférentiellement décrits à l'aide d'un langage du type SIDL (en anglais "Service Interface Définition Language"), mais tout autre type de langage adapté à l'invention peut également être utilisé. De façon avantageuse, ledit module de présentation est construit à l'aide d'un langage du type XSL (en anglais "Extended Stylesheet Language").
Selon une caractéristique avantageuse de l'invention, au sein dudit module de génération de réponse, ladite au moins une application est composée, selon un premier langage spécifique, d'un conteneur service, décrivant ledit service, et d'au moins un conteneur contexte, correspondant chacun à une étape de ladite navigation.
Afin de faciliter la lecture, un tel premier langage spécifique sera appelé, dans la suite de la description, langage MDSP (en anglais "Multi - Device Server Page"). Chaque application est ainsi composée d'un conteneur service et d'un ou plusieurs conteneurs contexte. Le conteneur service permet de décrire les instructions à effectuer au lancement de l'application. Il permet également de déclarer des entités (par exemple des variables ou des procédures) utilisables dans toute l'application considérée. Le conteneur contexte permet quant à lui de décrire un contexte, c'est-à-dire une étape de la navigation au sein de l'application considérée.
Il existe un unique conteneur service dans chaque application. Cependant, comme exposé dans la suite de la description, l'invention met en œuvre des instructions permettant, au cours d'un session, de changer de service. Pour chaque utilisateur d'un terminal de consultation, l'émission d'une requête et la visualisation de sa réponse, au cours d'une unique session, peut donc être associée à une pluralité de services.
Avantageusement, un conteneur est composé d'au moins un composant, permettant de regrouper au moins une instruction. De façon avantageuse, un tel système selon l'invention met en œuvre six types de composants : des composants de type "point d'entrée", permettant de décrire une première pluralité d'opérations que ledit module de génération de réponse doit effectuer au lancement de l'exécution d'un conteneur service ou d'un conteneur contexte ; des composants de type "attributs", permettant de décrire une pluralité de variables utilisables dans ledit conteneur courant ; des composants de type "méthode", permettant de regrouper une pluralité desdites au moins une instruction au sein d'une procédure ; - des composants de type "imports", permettant de décrire ledit au moins un objet nécessaire audit module de génération de réponse, pour générer ladite réponse à ladite requête relative à une application donnée ; des composants de type "traitement", permettant de décrire une seconde pluralité d'opérations que ledit module de génération de réponse doit effectuer en réponse à une action réalisée par un terminal ; des composants de type "contenu", permettant de décrire lesdites informations fournies à un terminal au sein de ladite réponse et/ou de décrire ladite au moins une action que peut réaliser ledit terminal à une étape de ladite navigation donnée. On présente, en annexe 1, des exemples de composants des types exposés ci-dessus. Cette annexe, de même que les suivantes, fait bien sûr partie de la présente description à part entière.
Ainsi, un composant de type point d'entrée est caractérisé par son nom, éventuellement des paramètres, et l'ensemble des instructions que le module de génération de réponse doit effectuer au lancement de l'exécution du conteneur service ou du conteneur contexte auquel appartient un tel composant de type "point d'entrée".
Un composant de type attribut permet quant à lui de décrire des variables utilisables dans tous les composants du conteneur courant. Ainsi, si le composant attribut appartient à un conteneur service, les variables qu'il déclare sont accessibles depuis tous les contextes de l'application considérée.
L'ensemble des instructions d'un composant de type contenu permettent, lorsqu'elles sont exécutées, de générer un arbre XML contenant l'ensemble des informations que le système de publication multi - terminal selon l'invention propose au terminal ayant émis la requête considérée.
Avantageusement, un tel système selon l'invention met en œuvre les quatre types d'instructions suivants : des instructions de type "contenu", permettant de générer une partie de ladite réponse sous un format de présentation générique ; - des instructions de type "manipulation de variables", permettant de déclarer et/ou de manipuler au moins une variable ; des instructions de type "navigation", permettant de changer de contexte courant et/ou d'application courante ; des instructions de type "utilisation", pouvant être utilisées par des instructions et/ou des composants.
Selon une première caractéristique avantageuse de l'invention, lesdites instructions de type "contenu" appartiennent au groupe comprenant : une instruction "contenu - littéral", permettant de décrire une chaîne de caractères de ladite réponse sous un format générique ; - une instruction "contenu - objet", permettant de décrire un objet ; une instruction "contenu - liste", permettant de décrire une liste d'objets ; une instruction "contenu - item", permettant de décrire un élément d'une liste ; une instruction "contenu - membre", permettant de décrire un membre d'un objet ; une instruction "contenu - sélection", permettant de sélectionner un item dans une liste ; une instruction "contenu - sélection - multiple", permettant de sélectionner au moins un item dans une liste ; - une instruction "contenu - entrée", permettant de décrire un item de type
"entrée" par lequel ledit terminal ayant formulé ladite requête peut entrer une valeur ; une instruction "contenu - défilement - action", permettant de se déplacer au sein d'une liste ; - une instruction "contenu - action", permettant de décrire une action ; une instruction "contenu - action - changement - de - contexte", permettant de décrire une action qui permet audit terminal ayant formulé ladite requête de changer de contexte ; une instruction "contenu - action - contexte - précédent", permettant audit terminal ayant formulé ladite requête de revenir au contexte précédent.
Ainsi, l'instruction "contenu - littéral", qui permet de décrire une chaîne de caractères à insérer dans l'arbre XML constitutif de la réponse, se caractérise par la chaîne de caractères à insérer et le nom du nœud de l'arbre XML généré.
L'instruction "contenu - objet" permet, quant à elle, de décrire un objet SIDL que le système selon l'invention propose au terminal ayant émis la requête traitée. Un tel objet peut être référencé par son nom dans tous les composants du contexte auquel appartient le composant de type "contenu". Pour que le composant de type "contenu" qui contient cette instruction soit correctement exécuté, le "contenu - objet" doit être initialisé avant l'appel de l'instruction exécutant le composant "contenu".
On présente, en annexe 2, quelques exemples d'instructions de type "contenu".
Selon une deuxième caractéristique avantageuse de l'invention, lesdites instructions de type "manipulation de variables" appartiennent au groupe comprenant : une instruction "objet", permettant de déclarer une variable de type
"objet" ; une instruction "liste", permettant de déclarer une variable de type "liste" ; une instruction "simple", permettant de déclarer une variable de type "simple", distinct dudit type "objet" et dudit type "liste " ; une instruction "créer", permettant de construire un objet ou une liste d'objets ; une instruction "établissement", permettant d'affecter une valeur à une variable ; - une instruction "liste - déplacer", permettant de déplacer un pointeur courant d'une liste, en spécifiant un pas de déplacement ; une instruction "liste - déplacer - vers", permettant de déplacer un pointeur courant d'une liste, en spécifiant une nouvelle position dudit pointeur.
En effet, le langage MDSP permet de déclarer et de manipuler des variables, qui peuvent être utilisées pour stocker des informations ou pour transmettre des paramètres.
Ainsi, l'instruction "objet" permet de déclarer une variable de type objet.
Cet objet peut être référencé par son nom dans tous les composants du conteneur courant. Avant d'être référencé, il doit être initialisé à l'aide d'une instruction prédéterminée. L'instruction "objet" se caractérise par le nom de la variable déclarée et par une classe SIDL de l'objet.
L'instruction "simple" permet quant à elle de déclarer une variable de type simple, c'est-à-dire une variable pouvant contenir une chaîne de caractères, un entier ou un flottant. Elle se caractérise par le nom de la variable et par la valeur que prend éventuellement cette variable à l'initialisation.
L'instruction "créer" permet de construire un objet ou une liste d'objets SIDL déclarés dans le contexte courant ou dans le service courant. Elle se caractérise par le nom de la variable à construire, le constructeur SIDL à utiliser, et les valeurs affectées aux paramètres du constructeur. On présente, en annexe 3, quelques exemples d'instructions de type "manipulation de variables".
Selon une troisième caractéristique avantageuse de l'invention, lesdites instructions de type "navigation" appartiennent au groupe comprenant : - une instruction "changer - contexte", permettant d'instancier un nouveau contexte ; une instruction "changer - service", permettant d'instancier un nouveau service ; une instruction " contexte - précédent", permettant de revenir au contexte précédent dans le service courant ; une instruction "service - précédent", permettant de revenir au contexte précédent avec le dernier contexte dudit service.
En effet, à un instant donné, pour un client donné (c'est-à-dire pour un terminal donné ayant émis une requête à destination du système de publication multi - terminal selon l'invention), il existe un unique contexte courant et un unique service courant. Le langage MDSP permet de changer ce contexte courant et ce service courant par l'entremise d'instructions de type "navigation".
Ainsi, une instruction "contexte-précédent" permet de revenir à un contexte précédent dans le service courant. Le contexte courant devient alors ce contexte, dans l'état où on l'a quitté la dernière fois. La présentation retournée au terminal ayant émis la requête correspond donc à celle décrite par le dernier composant de type "contenu" exécuté sur ce contexte.
On présente, en annexe 4, quelques exemples d'instructions de type "navigation". Selon une quatrième caractéristique avantageuse de l'invention, lesdites instructions de type "utilisation" appartiennent au groupe comprenant : une instruction "appel", permettant d'appeler un composant "méthode" dans le contexte ou le service courant ; une instruction "si", permettant d'établir une condition sur un ensemble d'instructions ; une instruction "sinon", faisant suite à une instruction "si" et permettant d'établir une condition sur un ensemble d'instructions ; une instruction "sinon - si", faisant suite à une instruction "si" et permettant d'établir au moins une autre condition sur ledit ensemble d'instructions ; une instruction "exécuter - contenu", permettant de générer une présentation desdites informations décrites dans un composant "contenu" ; une instruction "SIDL - import", permettant de spécifier un objet à utiliser dans le service courant ; - une instruction "paramètre - liste", permettant de regrouper des déclarations de paramètres ; une instruction "paramètre", permettant de spécifier la valeur d'un paramètre ; une instruction "faire", permettant de regrouper dans un composant du type "traitement" des actions à effectuer au lancement de l'exécution d'un contexte ; une instruction "sur", permettant de regrouper des conditions devant être validées pour qu'un composant du type "traitement" s'exécute.
En effet, il existe également, au sein du langage MDSP, des instructions diverses qui peuvent être utilisées par des instructions ou des composants.
Ainsi, une instruction "appel" permet d'appeler une méthode (c'est - à - dire un composant du type "méthode") déclarée dans le contexte courant ou dans le service courant. Elle se caractérise par le nom de la méthode appelée et par les valeurs affectées aux paramètres de la méthode. Une instruction "exécuter - contenu" permet de déclencher la génération de la présentation des informations décrites par un composant contenu. Elle se caractérise par le nom du contenu dont on veut générer la présentation et le nom du modèle XSL que l'on veut utiliser, si l'on ne veut pas utiliser celui du contenu.
On présente, en annexe 5, quelques exemples d'instructions de type "utilisation". Avantageusement, à la réception par ledit au moins un module de création d'objets d'une demande d'au moins un objet, ladite demande venant dudit module de génération de réponse, ladite au moins une fonction de création d'objets met en œuvre au moins une sous-fonction d'extraction, permettant de renseigner le contenu d'au moins un membre relatif à la structure dudit au moins un objet.
De façon avantageuse, ladite au moins une fonction de création d'objets comprend en outre une sous-fonction de comparaison dudit au moins un objet sur lequel porte ladite demande avec une liste d'objets préalablement au moins partiellement créés, de façon à ne mettre en œuvre ladite au moins une sous- fonction d'extraction que pour la création d'objets non préalablement créés et/ou pour compléter des objets préalablement partiellement créés.
Ainsi, si un objet a déjà été créé en réponse à une requête, traitée précédemment par le système de publication multi - terminal selon l'invention, cet objet est réutilisé dans l'élaboration de la réponse à la requête en cours de traitement, et est directement envoyé au module de génération de réponse.
Avantageusement, au sein dudit module Webbike, chaque sous-fonction d'extraction est composée, selon un second langage spécifique, d'au moins une page Webbike comprenant au moins un nœud Webbike, et ladite au moins une page Webbike est synchronisée avec au moins un document exprimé selon un langage de type "markup" d'au moins une source de données, ledit au moins un document comprenant lui-même au moins un nœud d'un langage de type "markup", ladite synchronisation permettant à un nœud Webbike de se positionner sur un nœud d'un langage de type "markup" afin d'en extraire des données brutes en vue de ladite création d'objets. Dans toute la suite du document, un tel second langage spécifique est appelé langage Webbike : le langage Webbike permet de créer des objets SIDL et d'initialiser la valeur de leurs attributs, à partir d'informations contenues dans une source de données d'un langage de type "markup" Le langage Webbike permet de décrire un service complet. Par conséquent, une page Webbike donnée peut contenir la description de plusieurs documents exprimés selon un langage de type "markup" associés, par exemple de plusieurs pages HTML quelle que soit l'adresse du serveur qui les fournit.
Le principe d'un tel langage Webbike est d'indiquer au module de création d'objets appelé module Webbike, comment rechercher de l'information dans les pages HTML, ou dans les documents XML, par exemple. Dans ce dessein, de nombreux nœuds Webbike (aussi appelés tags Webbike) permettent de se synchroniser avec la source d'un langage de type "markup" considérée. La synchronisation permet au module Webbike de se positionner sur un nœud d'un langage de type "markup", et d'en extraire des informations, telles que la valeur de ses attributs, par exemple, afin de les affecter aux membres d'objets SIDL.
De façon avantageuse, au sein dudit module Webbike, à la réception d'une demande d'au moins un premier objet, ladite sous-fonction d'extraction permet en outre de renseigner le contenu d'au moins un membre d'au moins un second objet, distinct dudit au moins un premier objet, lorsque des données brutes permettant de renseigner ledit contenu sont présentes au sein dudit document avec lequel est synchronisé ladite au moins une page Webbike.
Ainsi, lorsque le module de création d'objets selon l'invention accède, par exemple, à une page Web, il crée, au moins partiellement, tous les objets susceptibles d'être créés à partir des informations contenues dans cette page Web. La sous-fonction d'extraction extrait donc toutes les données brutes permettant de renseigner le contenu des membres d'objets, y compris des objets sur lesquels la demande traitée ne porte pas.
De cette façon, le module de création d'objets selon l'invention optimise l'accès aux sources de données, en ne parcourant et analysant qu'une seule fois chacune des pages Web, ou des documents XML contenus dans les sources de données. À titre d'exemple, le module de création d'objets accède à une page Web donnée pour créer un objet "film" : il extrait alors également les données brutes contenues dans la page et permettant de renseigner au moins certains des membres des objets "metteur en scène" et "festival de cinéma". Selon une caractéristique avantageuse de l'invention, il existe au moins les trois types de nœuds Webbike suivants : des nœuds Webbike de type synchronisation, permettant de rechercher un nœud d'un langage de type "markup" ou une "frame" d'un nœud d'un langage de type "markup" dans ledit au moins un document exprimé selon un langage de type "markup", afin de se positionner sur ledit nœud d'un langage de type "markup" ou sur ladite "frame" ; des nœuds Webbike de type structure, permettant de définir au moins une condition d'exécution desdits nœuds Webbike de type synchronisation ; - des nœuds Webbike de type commande, permettant de mettre en œuvre au moins une opération prédéterminée après s'être positionné sur ledit nœud d'un langage de type "markup" ou sur ladite "frame".
L'ensemble des nœuds Webbike constitue un arbre d'instructions Webbike commandant un interpréteur pour permettre de "naviguer" au sein de la source de données analysée. Une telle navigation est déclenchée par la réception, par le module Webbike, d'une demande de création d'objets.
Il existe, selon l'invention, de nombreux nœuds de type synchronisation permettant de se synchroniser sur un nœud d'un langage de type "markup" de la page ou du document analysé(e) par le module de création d'objets. On peut citer, à titre d'exemple, un nœud Webbike du type permettant de se synchroniser sur le prochain commentaire HTML, ou un nœud Webbike du type permettant de conditionner une synchronisation sur le contenu d'un nœud d'un langage de type
"markup". Cette condition de synchronisation peut notamment consister à effectuer une recherche d'expressions régulières au sein du contenu dudit nœud d'un langage de type "markup". Il est à noter qu'une telle recherche d'expressions régulières est également utilisée, au sein d'une page Web, dans le système de publication multi - terminal "Portai - To - Go", mais dans un tout autre but
(recherche directe de motifs dans une page, sans respect de l'arborescence de la page, et non pas synchronisation sur les nœuds HTML de cette page, dans le dessein d'extraire les données brutes contenues dans chacun des nœuds). Avantageusement, il existe en outre au moins un des types de nœuds Webbike suivants: des nœuds Webbike du type permettant la définition d'une sous-fonction d'extraction ; (tag Webbike) - des nœuds Webbike du type permettant l'indication du ou des objet(s) utilisé(s) dans une sous-fonction d'extraction ; (tag implements) des nœuds Webbike du type permettant la définition d'une page Webbike ;
(tag page) des nœuds Webbike du type pouvant être réutilisés avec éventuellement une liste de paramètres ; (tag method) des nœuds Webbike du type permettant la déclaration des paramètres d'une page ou d'un nœud réutilisable ; (tag param-list) des nœuds Webbike du type permettant d'appeler une autre page Webbike sans se synchroniser sur un nœud d'un langage de type "markup" ; (tag link) des nœuds Webbike du type permettant d'appeler un nœud de type réutilisable ; (tag call) des nœuds Webbike du type permettant de faire le lien vers une autre page
Webbike ; (tag action) - des nœuds Webbike du type permettant la définition d'une URL dynamique pour une page HTML ; (tag dynamic-url) des nœuds Webbike du type permettant d'affecter une valeur à un paramètre ; (tag param) des nœuds Webbike du type permettant de répéter une séquence d'au moins un nœud Webbike ; (tag multiple) des nœuds Webbike du type permettant d'inclure au moins une commande dans un emplacement normalement non autorisé d'une séquence d'au moins un nœud Webbike ; (tag block) des nœuds Webbike du type permettant de définir au moins deux façons de se synchroniser selon le contenu d'un document ; (tag switch) des nœuds Webbike du type permettant d'interpréter de façon conditionnelle une séquence d'au moins un nœud Webbike. (tag if/else) On présente, en annexe 6, des exemples de la syntaxe associée à certains des nœuds Webbike décrits ci-dessus. De façon avantageuse, lesdits nœuds Webbike de type commande appartiennent au groupe comprenant : des nœuds Webbike du type permettant de définir un bloc d'au moins une commande associé à un nœud (tag Webbike) du type permettant la définition d'une sous-fonction d'extraction ; (tag command) - des nœuds Webbike du type permettant l'extraction du contenu textuel d'un nœud d'un langage de type "markup" ; (tag body) des nœuds Webbike du type permettant l'extraction d'au moins un attribut du nœud d'un langage de type "markup" courant ; (tag attributes) des nœuds Webbike du type permettant de désigner une valeur constante ; (tag constant) des nœuds Webbike du type permettant d'assurer des fonctions de transformation des informations extraites d'un fichier exprimé selon un langage de type "markup". (function - substring, function - wordextract, f unction - check - url, function - java) Selon une technique avantageuse de l'invention, ladite au moins une commande, d'un bloc défini par un nœud Webbike, appartient au groupe comprenant : les commandes de création d'objets ; les commandes de modification d'au moins un membre d'un objet. II existe ainsi, notamment, une commande de création d'un nouvel objet
SIDL, une commande permettant de mettre à jour les membres d'un objet SIDL, et une commande permettant d'ajouter du texte à un membre d'objet SIDL.
Avantageusement, il existe au moins les deux types de page Webbike suivants : des pages Webbike statiques, analysées au lancement de ladite sous- fonction d'extraction ; des pages Webbike dynamiques, accessibles à partir d'une autre page Webbike par un nœud Webbike d'un type particulier, dit lien Webbike. Ainsi, les pages statiques ont une URL fixe, spécifiée dans un nœud
Webbike donné, appelé nœud "page", et sont analysées au lancement de l'application. Il faut généralement au moins une page statique au sein d'un service. Les pages dynamiques sont atteintes à l'aide d'un lien Webbike. Une page dynamique peut définir des paramètres permettant de passer des objets de page en page. Un paramètre peut être un objet simple, comme une chaîne de caractères, ou un objet SIDL.
De façon avantageuse, il existe au moins un nœud Webbike de type synchronisation spécifique permettant de rechercher un nœud d'un langage de type "markup" prédéterminé, afin de se positionner sur ledit nœud d'un langage de type "markup" prédéterminé, et, en outre, un nœud Webbike de type synchronisation générique permettant de rechercher un nœud d'un langage de type "markup" non - prédéterminé mais spécifié en paramètre, afin de se positionner sur ledit nœud d'un langage de type "markup" non - prédéterminé.
En effet, les langages de type "markup", tels que XML, WML ou HTML sont trop riches pour pouvoir fournir un nœud de synchronisation Webbike pour chaque nœud d'un langage de type "markup" existant. Afin de ne pas surcharger inutilement le langage Webbike, il existe, selon l'invention, un nœud Webbike de type synchronisation générique, qui permet de se synchroniser sur n'importe quel nœud d'un langage de type "markup", à condition de préciser le nom de l'élément sur lequel on veut se synchroniser.
Préférentiellement, au moins certains des nœuds de type synchronisation tiennent compte de conditions d'extraction portant sur des attributs et/ou sur un contenu textuel et/ou sur au moins un nœud fils d'un nœud d'un langage de type "markup" trouvé. Si plusieurs nœuds imbriqués répondent aux critères établis dans les conditions d'extraction, le premier nœud rencontré est généralement retenu.
De façon préférentielle, ledit module Webbike met en œuvre une fonction de gestion des cookies. Ainsi, les cookies envoyés par un serveur HTTP lors de la récupération d'une page HTML sont stockés au niveau du module Webbike. Ils sont renvoyés automatiquement par le module Webbike lorsqu'il accède à des pages qui correspondent au domaine du cookie. Certains sites Web dépendant de la gestion des cookies, il est important d'identifier la ressource qui provoque l'émission du cookie, afin d'y accéder à partir du module Webbike au moment opportun.
Dans un mode de réalisation avantageux de l'invention, au moins l'un desdits premier et second langages spécifiques est construit à l'aide d'un langage du type XML.
De manière avantageuse, ledit langage de type "markup" appartient au groupe comprenant : les langages de type XML (en anglais "Extended Markup Language") ; les langages de type HTML (en anglais "HyperText Markup Language") ; les langages de type SGML (en anglais "Standard Generalized Markup
Language") et dérivés ; - les langages de type WML (en anglais "Wireless Markup Language").
L'invention concerne également un procédé de mise en œuvre d'un système selon l'une quelconque des revendications 1 à 26, caractérisé en ce qu'il comprend les étapes suivantes : un terminal émet une requête relative à une application donnée à destination dudit système ; pour élaborer une réponse à ladite requête, ledit module de génération de réponse émet une demande d'au moins un objet à destination dudit au moins un module de création d'objets, de façon à renseigner la pluralité de contextes de ladite application ; ledit au moins un module de création d'objets crée ledit au moins un objet et le renvoie audit module de génération de réponse ; ledit module de génération de réponse génère une réponse sous un format de présentation générique, en mettant en œuvre ladite navigation selon ladite politique de navigation au sein de ladite pluralité de contextes ; ledit module de présentation reçoit dudit module de génération de réponse ladite réponse sous un format de présentation générique et la transforme en une réponse sous un format de présentation spécifique au type dudit terminal ayant formulé ladite requête ; - ledit système envoie ladite réponse sous un format de présentation spécifique audit terminal.
Avantageusement, ledit procédé est itératif, et la réponse à une requête donnée dépend de ladite politique de navigation et d'au moins une requête et/ou réponse précédente. D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 présente un synoptique des différents types de terminaux pouvant bénéficier d'un système de publication multi - terminal selon l'invention ; la figure 2 illustre l'architecture générale d'un système de publication multi - terminal vers les terminaux présentés en figure 1 ; la figure 3 présente un synoptique des différents modules mis en œuvre dans un système de publication multi - terminal selon l'invention ; la figure 4 décrit plus précisément l'architecture du système de publication multi - terminal illustré en figure 3 ; la figure 5 présente les différentes étapes mises en œuvre lors du traitement d'une requête adressée par un client du système de publication multi - terminal de la figure 3. Le principe général de l'invention repose sur la mise en œuvre d'un système de publication multi - terminal, reposant sur le traitement d'un service générique, indépendamment de son format dans une source de données et de sa présentation finale dans le terminal cible. On présente, en relation avec la figure 1, un synoptique des différents types de terminaux pouvant accéder à un service, extrait par exemple d'un site Web 1, à partir d'un système de publication multi - terminal 2 selon l'invention.
On distingue, par exemple, des terminaux de types divers tels qu'un terminal de type PDA (en anglais "Personal Digital Assistant") 3 ou 4, un téléphone mobile de type WAP (en anglais "Wireless Application Protocol") 5, un terminal de téléphonie fixe 6, un terminal de type Minitel 7, ou encore tout autre type de terminal, et notamment les terminaux légers 8, 9 et 10.
L'architecture générale d'un système de publication multi - terminal est présentée en figure 2. Les terminaux 3, 4 et 5, déjà illustrés en figure 1, et un terminal 20 de type ordinateur personnel accèdent via un protocole du type HTTP aux données 21 extraites et diffusées sur le réseau mondial Internet ou sur tout autre réseau de type internet par le serveur Web 22.
Le terminal WAP 5 ne supportant pas le protocole de type HTTP, une passerelle WAP 23 est mise en œuvre, de façon à réaliser une interface entre le protocole de type HTTP et le protocole de type WTP utilisé sur le réseau mobile. On présente désormais, en relation avec la figure 3, les différents modules mis en œuvre dans un système de publication multi - terminal selon l'invention, dans le cas particulier où les sources de données mises en œuvre sont des sites Web composés d'une ou plusieurs page(s) HTML. Un tel système de publication multi - terminal est alors composé de trois modules principaux : un module 30 de création d'objets ; un module 31 de génération de réponse sous un format générique, utilisant le langage appelé MDSP ; - un module 32 de présentation. Le module 30 de création d'objets met en œuvre une sous-fonction d'extraction de données contenues dans les pages HTML, en réalisant une synchronisation sur les nœuds HTML. Il crée des objets à l'aide du langage SIDL
(en anglais "service Interface Définition Language"), puis les transmet au module 31 de génération de réponse.
Le module 31 de génération de réponse sous un format générique met en œuvre un langage informatique basé sur un langage du type XML. Il récupère les objets SIDL créés par le module 30 de création d'objets
Le module 32 de présentation utilise des feuilles de style, spécifiques à chaque type de terminal de consultation, pour formater les données issues du module 31 de génération de réponse, c'est-à-dire l'arbre XML intermédiaire fourni par le module référencé 31, selon un format lisible par le terminal - destination.
On décrit plus précisément en relation avec la figure 4 l'architecture du système de publication multi - terminal, dont les différents modules sont illustrés en figure 3.
Certaines données, contenues dans une source de données 40 (par exemple, un fichier de type XML, un site Web, une base de données, etc.) sont extraites par un module de création d'objets 30, pour renseigner les membres de certains objets, nécessaires à la construction d'une réponse à un terminal de consultation 5. Le module 30 met en œuvre un langage spécifique, qui permet la création d'objets de type SID1 (en anglais "Service Interface Définition Language").
Les objets SIDL sont ensuite transmis au module 31 de génération de réponse sous un format de présentation générique, qui élabore une réponse sous forme d'un arbre de type XML.
Un tel arbre XML est ensuite traité par un module de présentation, qui met en œuvre un ensemble de feuilles de style 32. Chaque feuille de style est associée à un type de terminal de consultation, et permet de définir les critères de présentation spécifiques à chaque type de terminal. On peut ainsi envisager que le module de présentation utilise une feuille de style caractéristique des terminaux de type WAP, une feuille de style caractéristique des terminaux de type Minitel, une feuille de style caractéristique des terminaux de type PAD, etc.
Le module de présentation 32 peut ensuite fournir, au terminal 5 ayant émis une requête à destination du système de publication multi - terminal' selon l'invention, une réponse dont le contenu et la présentation sont adaptés au type du terminal de consultation 5 (ici, un terminal de type WAP).
Les modules 30 de création d'objets, 31 de génération de réponse, et 32 de présentation fonctionnent donc indépendamment, d'une part, de la nature de la source de données 40, et d'autre part, du type du terminal de consultation 5. On décrit désormais, en relation avec la figure 5, les différentes étapes mises en œuvre lors du traitement, par le système de publication multi - terminal, d'une requête provenant d'un terminal client.
Au cours d'une première étape, un client 50 disposant d'un terminal adapté au système de publication multi - terminal selon l'invention, émet une requête 51 d'accès à un ensemble d'informations. Par exemple, le client 50 peut demander l'accès à un site Web donné, ou à un ensemble d'informations contenues dans une base de données particulière. Le client 50 peut encore demander des informations que le système de publication multi - terminal selon l'invention doit, par exemple, partiellement extraire d'un site Web, partiellement extraire d'une base de données, et partiellement générer en mettant en œuvre un module de type java.
On peut ainsi envisager que le client 50 souhaite, par exemple, connaître la liste des événements culturels qui auront lieu dans une ville donnée au cours des prochains mois.
Selon le mode de réalisation illustré en figure 5, le système de publication multi - terminal selon l'invention comprend, outre les modules présentés en figures 3 et 4, un module d'interfaçage 59, permettant d'intercepter et d'analyser la requête 51.
Après analyse de la requête 51, le module d'interfaçage 59 détermine le type de terminal utilisé par le client 50 pour émettre la requête 51, de façon à ce que le système de publication multi - terminal selon l'invention puisse transmettre au client 50 une réponse dont le contenu et la présentation sont adaptés au type de terminal de consultation. Le module d'interfaçage 59 transmet ensuite sa requête au module de génération de réponse sous un format générique 31, au cours d'une étape référencée 52. Au cours d'une étape référencée 53, le module de génération de réponse 31 émet à son tour une requête à destination de l'ensemble de modules de création d'objets 30, de manière à requérir la création des objets nécessaires à la construction d'une réponse au client 50.
L'ensemble des modules de création d'objets 30 interroge un ensemble de sources de données, afin d'en extraire les informations demandées par le module de génération de réponse 31. Par exemple, un module de type java 302 génère certains objets SIDL, un module 301 de création d'objets, appelé Webbike, extrait des objets SIDL d'un ou plusieurs sites Web par synchronisation sur les tags HTML, et un module de création d'objets 302 créé des objets SIDL à partir des données brutes contenues dans une ou plusieurs bases de données.
Au cours d'une étape référencée 54, l'ensemble des modules de création d'objets 30 transmet au module de génération de réponse sous un format générique 31 les objets SIDL créés en réponse à la requête 53, ainsi que des objets SIDL, nécessaires à la génération d'une réponse à la requête 51 du client 50, créés précédemment par l'ensemble des modules de création d'objets 30. Par exemple, on peut envisager qu'une partie de la réponse transmise précédemment à un autre client 50 puisse être réutilisée pour l'élaboration d'une réponse à la requête 51 ; dans ce cas, l'ensemble de modules de création d'objets 30 transmet au module de génération de réponse 31 les objets déjà créés précédemment, par exemple par extraction d'un site Web et/ou d'une base de données et/ou d'un module java.
Dans ce dessein, à la réception d'une requête 53, l'ensemble des modules de création d'objets 30 met en œuvre une comparaison des objets nécessaires au module de génération de réponse 31 avec une liste d'objets précédemment créés, de manière à ne mettre en œuvre les fonctions d'extraction ou de génération d'objets que pour les objets non précédemment créés. Le module de génération de réponse sous un format générique 31 met alors en œuvre une navigation au sein de la pluralité de contextes relatifs au service requis par le client 50 au cours de l'étape 51. Une telle navigation au sein des contextes, dans lesquels sont regroupés les objets SIDL fournis par les modules de création d'objets 30, permet au module de génération de réponse sous un format générique 31 d'élaborer, au cours d'une étape référencée 55, un arbre de type XML.
Le module de présentation 32 traite alors cet arbre intermédiaire XML, de manière à présenter la réponse envoyée au client 50 sous un format adapté au type de terminal de consultation. Dans ce dessein, le module de présentation 32 utilise un ensemble de feuilles de style présentées en figure 4, et regroupant les caractéristiques de présentation propres à chaque type de terminal de consultation.
Au cours d'une étape référencée 56, le module de présentation 32 envoie la réponse, sous un format de présentation spécifique au type du terminal ayant formulé la requête 51, au module de génération de réponse 31. Le module 31 retourne alors la réponse finale au module d'interfaçage 59 au cours d'une étape référencée 57.
La réponse finale, sous un format de présentation adapté au type de terminal utilisé par le client 50, est ensuite acheminée vers le terminal de consultation, au cours d'une étape référencée 58.
ANNEXE 1 Composant de type "traitement"
<handler action = "OK"> <on> <valid field = "selectEvt"/>
</on> <do>
<change-context context "pageDuResume">
<param pram="unEvenement" value="selectEvt"/> </change-context>
</do> </handler>
Composant de type "méthode" <method name = "uneMethode"> <param-list>
<simple name = " unParametre "/> </param-list>
<if condition = "unParametre EQUAL 'retour'"> <previous-context> </if> <else> <else>
<change-context context = "PageDAide"/> </else> </method> ANNEXE 2
Instructions de type "contenu"
Instruction "contenu-item"
<content-item node-name = "ville-courante"> <content-member member = "nom"/> </content-item>
Instruction "contenu-défilement-action" Exemple <content-action-scroll name = "scrollEvenements">
Arbre XML généré <eop-action type = "scroll" direction = "previous" name = "name" value = "5.12-1" url = "hostaddress/l-l-l-17a=5.12-l" uri = "hostaddress/l-l-l-VI>
<eop-action type = "scroll" direction = "next" name = "name" value = "5.12-2" url = "hostaddressll-l-l-l =5.12-2" uri = " hostaddressl 1-1-1-1" l> ANNEXE 3
Instructions de type "manipulation de variables"
Instruction "liste"
<list name = "uneListe" class = "C_Ville"/>
Instruction "créer"
<create variable = "listeEvt" constructor = "StringEtCat"> <param param = "a_string" value = '"Paris'"/> <param param = "a_cat" value = "CatégorieCourante"/>
</create>
ANNEXE 4
Instructions de type "navigation"
Instruction "changer-contexte"
<change-context context = "Evénement" entrypoint = "fromLieux">
<param param = "unLieu" value = "lieuSelectionne"/> </change-contexf>
Instruction "changer-service"
<change-service service = "ErrorService" entrypoint = "BadName"> <param param = "a_msg" value = " ' le nom ' CAT inputNAME CAT ' est inconnu ' "/>
</change-service>
ANNEXE 5
Instruction de type "utilisation"
Instruction "sinon"
<if condition = "TERMINAL. Software.langage EQUAL 'html' "> <change-context context = "aideHTML"/>
</if> <else>
<change-context context ="AideVDXML"/>
</else>
Instruction "paramètre-liste"
<ρaram-list>
<simple name = "unPremierParam"/>
<object name = "unSecondParam" class = "C_Ville"/> </param-list>
ANNEXE 6 Nœuds Webbike du type permettant la définition d'une sous-fonction d'extraction :
<WebBike service="nouba" javascript="on"> <!- -liste des implements - -> <!- -liste de page - -> <!- -liste de method - -> </WebBike>
Nœuds Webbike du type permettant d'interpréter de façon conditionnelle une séquence d'au moins un nœud Webbike :
<if condition ="expression"> [<command>]
<!- - instructions WebBike- - > </if> <else>
[<command>]
<!- - instructions WebBike- - > </else>
Nœuds Webbike du type permettant la définition d'une URL dynamique pour une page HTML :
<dynamic-url base="http://..." [method="post"]>
<!- - liste des objets passés en paramètres à la page (liste de <param>). Ici le tag param associe un nom de paramètre de la page avec un
Nom de paramètre de la requête (paramètre d'un constructeur D'objet SIDL) - -> <!- - liste des paramètres à passer au CGI (liste de <url-param>). - -> </dynamic-url> Nœuds Webbike du type permettant la définition d'une page Webbike
<page name="root"
[url="http://www.nouba.voilà.fr"]
[parse-mode="service"]>
[<param-list>]
[<command>]
<!- -liste de <dynamic-url> - ->
<!- - instructions WebBike- - > </page>

Claims

REVENDICATIONS
1. Système de publication multi - terminal (2), du type offrant un accès à au moins une application correspondant à un service, permettant de fournir à une pluralité de terminaux (3-10), selon au moins deux types de terminal distincts, des informations contenues dans au moins une source d'informations (40), caractérisé en ce qu'il comprend : au moins un module de création d'objets (30, 301-303), permettant de fournir au moins une fonction de création d'objets à partir de données brutes extraites de ladite au moins une source d'informations et/ou générées par ledit au moins un module de création d'objets ; un module (31) de génération de réponse sous un format de présentation générique, en réponse à une requête (51) formulée par un terminal et relative à une application donnée, ladite application étant définie, au sein dudit module de génération de réponse, par une pluralité de contextes et une politique de navigation parmi lesdits contextes, chaque contexte comprenant au moins une action et ou au moins un objet, créé par ledit au moins un module de création d'objets, ladite réponse résultant d'une navigation selon ladite politique de navigation au sein de ladite pluralité de contextes ; - un module de présentation (32), permettant de transformer ladite réponse sous un format de présentation générique en une réponse sous un format de présentation spécifique au type dudit terminal ayant formulé ladite requête.
2. Système selon la revendication 1, caractérisé en ce que ladite réponse sous un format de présentation générique est un arbre de type XML ou de type SGML.
3. Système selon l'une quelconque des revendications 1 et 2, caractérisé en ce qu'il comprend en outre un module d'interfaçage (59) permettant d'intercepter et d'analyser ladite requête (51) formulée par un terminal, de manière à : identifier le type dudit terminal ; créer une nouvelle requête (52), sous un format de requête générique, destinée audit module de génération de réponse.
4. Système selon l'une quelconque des revendications 1 à 3, caractérisé en ce que chaque objet comprend au moins un membre relatif à la structure dudit objet et au moins un constructeur, ledit au moins un constructeur permettant audit au moins un module (30) de création d'objets de renseigner le contenu dudit au moins un membre.
5. Système selon l'une quelconque des revendications 1 à 4, caractérisé en ce que ledit au moins un module (30) de création d'objets appartient au groupe comprenant: un module (301) de création d'objets, appelé module Webbike, permettant de fournir au moins une fonction de création d'objets à partir de données brutes extraites d'au moins une source de données contenant au moins un document exprimé selon un langage de type "markup" ; un module (303) de création d'objets, permettant de fournir au moins une fonction de création d'objets à partir de données brutes extraites d'au moins une base de données du type SQL ; un module (302) de création d'objets, construit à partir d'un langage du type java, permettant de fournir au moins une fonction de création d'objets à partir de données brutes générées par ledit module de création d'objets et/ou extraites d'au moins une source d'informations prédéterminées.
6. Système selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ledit module (32) de présentation est construit à l'aide d'un langage du type
XSL.
7. Système selon l'une quelconque des revendications 1 à 6, caractérisé en ce qu'au sein dudit module (31) de génération de réponse, ladite au moins une application est composée, selon un premier langage spécifique, d'un conteneur service, décrivant ledit service, et d'au moins un conteneur contexte, correspondant chacun à une étape de ladite navigation.
8. Système selon la revendication 7, caractérisé en ce qu'un conteneur est composé d'au moins un composant, permettant de regrouper au moins une instruction.
9. Système selon la revendication 8, caractérisé en ce qu'il met en œuvre six types de composants : des composants de type "point d'entrée", permettant de décrire une première pluralité d'opérations que ledit module de génération de réponse doit effectuer au lancement de l'exécution d'un conteneur service ou d'un conteneur contexte ; des composants de type "attributs", permettant de décrire une pluralité de variables utilisables dans ledit conteneur courant ; des composants de type "méthode", permettant de regrouper une pluralité desdites au moins une instruction au sein d'une procédure ; des composants de type "imports", permettant de décrire ledit au moins un objet nécessaire audit module de génération de réponse, pour générer ladite réponse à ladite requête relative à une application donnée ; des composants de type "traitement", permettant de décrire une seconde pluralité d'opérations que ledit module de génération de réponse doit effectuer en réponse à une action réalisée par un terminal ; des composants de type "contenu", permettant de décrire lesdites informations fournies à un terminal au sein de ladite réponse et/ou de décrire ladite au moins une action que peut réaliser ledit terminal à une étape de ladite navigation donnée.
10. Système selon l'une quelconque des revendications 8 et 9, caractérisé en ce qu'il met en œuvre les quatre types d'instructions suivants : des instructions de type "contenu", permettant de générer une partie de ladite réponse sous un format de présentation générique ; - des instructions de type "manipulation de variables", permettant de déclarer et/ou de manipuler au moins une variable ; des instructions de type "navigation", permettant de changer de contexte courant et/ou d'application courante ; des instructions de type "utilisation", pouvant être utilisées par des instructions et/ou des composants.
11. Système selon la revendication 10, caractérisé en ce que lesdites instructions de type "contenu" appartiennent au groupe comprenant : une instruction "contenu-littéral", permettant de décrire une chaîne de caractères de ladite réponse sous un format générique ; - une instruction "contenu-objet", permettant de décrire un objet ; une instruction "contenu-liste", permettant de décrire une liste d'objets ; une instruction "contenu-item", permettant de décrire un élément d'une liste ; une instruction "contenu-membre", permettant de décrire un membre d'un objet ; une instruction "contenu-sélection ", permettant de sélectionner un item dans une liste ; une instruction "contenu-sélection-multiple", permettant de sélectionner au moins un item dans une liste ; - une instruction "contenu-entrée", permettant de décrire un item de type
"entrée" par lequel ledit terminal ayant formulé ladite requête peut entrer une valeur ; une instruction "contenu-défilement-action ", permettant de se déplacer au sein d'une liste ; - une instruction "contenu-action", permettant de décrire une action ; une instruction "contenu-action-changement-de-contexte", permettant de décrire une action qui permet audit terminal ayant formulé ladite requête de changer de contexte ; une instruction "contenu-action-contexte-précédent", permettant audit terminal ayant formulé ladite requête de revenir au contexte précédent.
12. Système selon l'une quelconque des revendications 10 et 11, caractérisé en ce que lesdites instructions de type "manipulation de variables" appartiennent au groupe comprenant : une instruction "objet", permettant de déclarer une variable de type "objet" ; une instruction "liste", permettant de déclarer une variable de type "liste" ; une instruction "simple", permettant de déclarer une variable de type "simple", distinct dudit type "objet" et dudit type "liste " ; une instruction "créer", permettant de construire un objet ou une liste d'objets ; une instruction "établissement", permettant d'affecter une valeur à une variable ; une instruction "liste-déplacer", permettant de déplacer un pointeur courant d'une liste, en spécifiant un pas de déplacement ; - une instruction "liste-déplacer-vers", permettant de déplacer un pointeur courant d'une liste en spécifiant une nouvelle position dudit pointeur.
13. Système selon l'une quelconque des revendications 10 à 12, caractérisé en ce que lesdites instructions de type "navigation" appartiennent au groupe comprenant : - une instruction "changer-contexte", permettant d'instancier un nouveau contexte ; une instruction "changer-service", permettant d'instancier un nouveau service ; une instruction " contexte-précédent", permettant de revenir au contexte précédent dans le service courant ; une instruction "service-précédent", permettant de revenir au contexte précédent avec le dernier contexte dudit service.
14. Système selon l'une quelconque des revendications 10 à 13, caractérisé en ce que lesdites instructions de type "utilisation" appartiennent au groupe comprenant : une instruction "appel", permettant d'appeler un composant "méthode" dans le contexte ou le service courant ; une instruction "si", permettant d'établir une condition sur un ensemble d'instructions ; une instruction "sinon", faisant suite à une instruction "si" et permettant d'établir une condition sur un ensemble d'instructions ; une instruction "sinon-si", faisant suite à une instruction "si" et permettant d'établir au moins une autre condition sur ledit ensemble d'instructions ; - une instruction "exécuter-contenu", permettant de générer une présentation desdites informations décrites dans un composant "contenu" ; une instruction " si dl -import", permettant de spécifier un objet à utiliser dans le service courant ; une instruction "paramètre-liste", permettant de regrouper des déclarations de paramètres ; une instruction "paramètre", permettant de spécifier la valeur d'un paramètre ; une instruction "faire", permettant de regrouper dans un composant du type
"traitement" des actions à effectuer au lancement de l'exécution d'un contexte ; une instruction "sur", permettant de regrouper des conditions devant être validées pour qu'un composant du type "traitement" s'exécute.
15. Système selon l'une quelconque des revendications 1 à 14, caractérisé en ce qu'à la réception par ledit au moins un module (30) de création d'objets d'une demande d'au moins un objet, ladite demande venant dudit module (31) de génération de réponse, ladite au moins une fonction de création d'objets met en œuvre au moins une sous-fonction d'extraction, permettant de renseigner le contenu d'au moins un membre relatif à la structure dudit au moins un objet.
16. Système selon la revendication 15, caractérisé en ce que ladite au moins une fonction de création d'objets comprend en outre une sous-fonction de comparaison dudit au moins un objet sur lequel porte ladite demande avec une liste d'objets préalablement au moins partiellement créés, de façon à ne mettre en œuvre ladite au moins une sous-fonction d'extraction que pour la création d'objets non préalablement créés et/ou pour compléter des objets préalablement partiellement créés.
17. Système selon l'une quelconque des revendications 15 et 16, caractérisé en ce qu'au sein dudit module Webbike (301), chaque sous-fonction d'extraction est composée, selon un second langage spécifique, d'au moins une page Webbike comprenant au moins un nœud Webbike, et en ce que ladite au moins une page Webbike est synchronisée avec au moins un document exprimé selon un langage de type "markup" d'au moins une source de données, ledit au moins un document comprenant lui-même au moins un nœud d'un langage de type "markup", ladite synchronisation permettant à un nœud Webbike de se positionner sur un nœud d'un langage de type "markup" afin d'en extraire des données brutes en vue de ladite création d'objets.
18. Système selon les revendications 4 et 17, caractérisé en ce qu'au sein dudit module Webbike, à la réception d'une demande d'au moins un premier objet, ladite sous-fonction d'extraction permet en outre de renseigner le contenu d'au moins un membre d'au moins un second objet, distinct dudit au moins un premier objet, lorsque des données brutes permettant de renseigner ledit contenu sont présentes au sein dudit document avec lequel est synchronisé ladite au moins une page Webbike.
19. Système selon l'une quelconque des revendications 17 et 18, caractérisé en ce qu'il existe au moins les trois types de nœuds Webbike suivants : - des nœuds Webbike de type synchronisation, permettant de rechercher un nœud d'un langage de type "markup" ou une "frame" d'un nœud d'un langage de type "markup" dans ledit au moins un document exprimé selon un langage de type "markup", afin de se positionner sur ledit nœud d'un langage de type "markup" ou sur ladite "frame" ; - des nœuds Webbike de type structure, permettant de définir au moins une condition d'exécution desdits nœuds Webbike de type synchronisation ; des nœuds Webbike de type commande, permettant de mettre en œuvre au moins une opération prédéterminée après s'être positionné sur ledit nœud d'un langage de type "markup" ou sur ladite "frame".
20. Système selon la revendication 19, caractérisé en ce qu'il existe en outre au moins un des types de nœuds Webbike suivants: des nœuds Webbike du type permettant la définition d'une sous-fonction d'extraction ; - des nœuds Webbike du type permettant l'indication du ou des objet(s) utilisé(s) dans une sous-fonction d'extraction ; des nœuds Webbike du type permettant la définition d'une page Webbike ; des nœuds Webbike du type pouvant être réutilisés avec éventuellement une liste de paramètres ; - des nœuds Webbike du type permettant la déclaration des paramètres d'une page ou d'un nœud réutilisable ; des nœuds Webbike du type permettant d'appeler une autre page Webbike sans se synchroniser sur un nœud d'un langage de type "markup" ; des nœuds Webbike du type permettant d'appeler un nœud de type réutilisable ; des nœuds Webbike du type permettant de faire le lien vers une autre page
Webbike ; des nœuds Webbike du type permettant la définition d'une URL dynamique pour une page HTML ; - des nœuds Webbike du type permettant d'affecter une valeur à un paramètre ; des nœuds Webbike du type permettant de répéter une séquence d'au moins un nœud Webbike ; des nœuds Webbike du type permettant d'inclure au moins une commande dans un emplacement normalement non autorisé d'une séquence d'au moins un nœud Webbike ; des nœuds Webbike du type permettant de définir au moins deux façons de se synchroniser selon le contenu d'un document ; des nœuds Webbike du type permettant d'interpréter de façon conditionnelle une séquence d'au moins un nœud Webbike.
21. Système selon la revendication 19, caractérisé en ce que lesdits nœuds Webbike de type commande appartiennent au groupe comprenant : des nœuds Webbike du type permettant de définir un bloc d'au moins une commande associé à un nœud du type permettant la dé inition d'une sous- fonction d'extraction ; des nœuds Webbike du type permettant l'extraction du contenu textuel d'un nœud d'un langage de type "markup" ; des nœuds Webbike du type permettant l'extraction d'au moins un attribut du nœud d'un langage de type "markup" courant ; - des nœuds Webbike du type permettant de désigner une valeur constante ; des nœuds Webbike du type permettant d'assurer des fonctions de transformation des informations extraites d'un fichier d'un langage de type "markup".
22. Système selon la revendication 21, caractérisé en ce que ladite au moins une commande, d'un bloc défini par un nœud Webbike, appartient au groupe comprenant : les commandes de création d'objets ; les commandes de modification d'au moins un membre d'un objet.
23. Système selon l'une quelconque des revendications 17 à 22, caractérisé en ce qu'il existe au moins les deux types de page Webbike suivants : des pages Webbike statiques, analysées au lancement de ladite sous- fonction d'extraction ; des pages Webbike dynamiques, accessibles à partir d'une autre page
Webbike par un nœud Webbike d'un type particulier, dit lien Webbike.
24. Système selon l'une quelconque des revendications 19 à 23, caractérisé en ce qu'il existe au moins un nœud Webbike de type synchronisation spécifique permettant de rechercher un nœud d'un langage de type "markup" prédéterminé, afin de se positionner sur ledit nœud d'un langage de type "markup" prédéterminé, et, en outre, un nœud Webbike de type synchronisation générique permettant de rechercher un nœud d'un langage de type "markup" non - prédéterminé mais spécifié en paramètre, afin de se positionner sur ledit nœud d'un langage de type "markup" non - prédéterminé.
25. Système selon l'une quelconque des revendications 19 à 24, caractérisé en ce que au moins certains des nœuds de type synchronisation tiennent compte de conditions d'extraction portant sur des attributs et/ou sur un contenu textuel et/ou sur au moins un nœud fils d'un nœud d'un langage de type "markup" trouvé.
26. Système selon l'une quelconque des revendications 5 à 25, caractérisé en ce que ledit module Webbike met en œuvre une fonction de gestion des cookies.
27. Système selon les revendications 7 et 17, caractérisé en ce qu'au moins l'un desdits premier et second langages spécifiques est construit à l'aide d'un langage du type XML.
28. Système selon l'une quelconque des revendications 17 à 27, caractérisé en ce que ledit langage de type "markup" appartient au groupe comprenant : les langages de type XML (en anglais "Extended Markup Language") ; - les langages de type HTML (en anglais "HyperText Markup Language") ; les langages de type SGML (en anglais "Standard Generalized Markup Language") et dérivés ; les langages de type WML (en anglais "Wireless Markup Language").
29. Procédé de mise en œuvre d'un système selon l'une quelconque des revendications 1 à 28, caractérisé en ce qu'il comprend les étapes suivantes : un terminal (3-10) émet une requête (51) relative à une application donnée à destination dudit système (2) ; pour élaborer une réponse à ladite requête, ledit module (31) de génération de réponse émet une demande d'au moins un objet à destination dudit au moins un module (30) de création d'objets, de façon à renseigner la pluralité de contextes de ladite application ; ledit au moins un module de création d'objets crée ledit au moins un objet et le renvoie audit module de génération de réponse ; ledit module de génération de réponse génère une réponse sous un format de présentation générique, en mettant en œuvre ladite navigation selon ladite politique de navigation au sein de ladite pluralité de contextes ; ledit module de présentation (32) reçoit dudit module de génération de réponse ladite réponse sous un format de présentation générique et la transforme en une réponse sous un format de présentation spécifique au type dudit terminal ayant formulé ladite requête ; ledit système envoie ladite réponse sous un format de présentation spécifique audit terminal.
30. Procédé selon la revendication 29, caractérisé en ce que ledit procédé est itératif, et en ce que la réponse à une requête donnée dépend de ladite politique de navigation et d'au moins une requête et/ou réponse précédente.
EP01936548A 2000-05-31 2001-05-16 Systeme de publication multi-terminal et procede de mise en oeuvre correspondant Withdrawn EP1285361A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR0007073 2000-05-31
FR0007073A FR2809844B1 (fr) 2000-05-31 2000-05-31 Systeme de publication multi-terminal et procede de mise en oeuvre correspondant
PCT/FR2001/001500 WO2001093094A1 (fr) 2000-05-31 2001-05-16 Systeme de publication multi-terminal et procede de mise en oeuvre correspondant

Publications (1)

Publication Number Publication Date
EP1285361A1 true EP1285361A1 (fr) 2003-02-26

Family

ID=8850897

Family Applications (1)

Application Number Title Priority Date Filing Date
EP01936548A Withdrawn EP1285361A1 (fr) 2000-05-31 2001-05-16 Systeme de publication multi-terminal et procede de mise en oeuvre correspondant

Country Status (5)

Country Link
US (1) US20030158894A1 (fr)
EP (1) EP1285361A1 (fr)
AU (1) AU2001262431A1 (fr)
FR (1) FR2809844B1 (fr)
WO (1) WO2001093094A1 (fr)

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7054946B2 (en) * 2000-12-06 2006-05-30 Intelliden Dynamic configuration of network devices to enable data transfers
US8219662B2 (en) 2000-12-06 2012-07-10 International Business Machines Corporation Redirecting data generated by network devices
US6978301B2 (en) 2000-12-06 2005-12-20 Intelliden System and method for configuring a network device
US7150037B2 (en) * 2001-03-21 2006-12-12 Intelliden, Inc. Network configuration manager
US8296400B2 (en) 2001-08-29 2012-10-23 International Business Machines Corporation System and method for generating a configuration schema
US7065562B2 (en) * 2001-11-26 2006-06-20 Intelliden, Inc. System and method for generating a representation of a configuration schema
GB2387729B (en) * 2002-03-07 2006-04-05 Chello Broadband N V Enhancement for interactive tv formatting apparatus
US6959329B2 (en) * 2002-05-15 2005-10-25 Intelliden System and method for transforming configuration commands
US20040028069A1 (en) * 2002-08-07 2004-02-12 Tindal Glen D. Event bus with passive queuing and active routing
US20040030771A1 (en) * 2002-08-07 2004-02-12 John Strassner System and method for enabling directory-enabled networking
US8010423B2 (en) 2002-08-29 2011-08-30 International Business Machines Corporation Anticipatory mobile system service brokering and resource planning from multiple providers
US20040078457A1 (en) * 2002-10-21 2004-04-22 Tindal Glen D. System and method for managing network-device configurations
US7447642B2 (en) * 2002-11-07 2008-11-04 International Business Machines Corporation Location based services revenue sharing and cost offsetting
US8027843B2 (en) * 2002-11-07 2011-09-27 International Business Machines Corporation On-demand supplemental diagnostic and service resource planning for mobile systems
US20040093299A1 (en) * 2002-11-07 2004-05-13 International Business Machines Corporation System and method for coalescing information for presentation to a vehicle operator
US20040230681A1 (en) * 2002-12-06 2004-11-18 John Strassner Apparatus and method for implementing network resources to provision a service using an information model
US9535679B2 (en) * 2004-12-28 2017-01-03 International Business Machines Corporation Dynamically optimizing applications within a deployment server
FI117656B (fi) * 2005-02-15 2006-12-29 Lumi Interactive Ltd Sisällön optimointi vastaanottaville päätelaitteille
CN107402747B (zh) * 2016-05-20 2019-08-20 中国科学院声学研究所 一种支持多终端类型的应用页面动态生成方法

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6049831A (en) * 1996-11-08 2000-04-11 Gte Laboratories Incorporated System for transmitting network-related information where requested network information is separately transmitted as definitions and display information
US6857102B1 (en) * 1998-04-07 2005-02-15 Fuji Xerox Co., Ltd. Document re-authoring systems and methods for providing device-independent access to the world wide web
US6055229A (en) * 1998-06-29 2000-04-25 Motorola, Inc. Method and apparatus in a wireless communication system for dynamically formatting application data to be transmitted
JP3202968B2 (ja) * 1998-06-30 2001-08-27 インターナショナル・ビジネス・マシーンズ・コーポレーション 表示制御情報生成方法及びコンピュータ
US6466232B1 (en) * 1998-12-18 2002-10-15 Tangis Corporation Method and system for controlling presentation of information to a user based on the user's condition
US6993575B2 (en) * 2000-02-22 2006-01-31 Oracle International Corporation Using one device to configure and emulate web site content to be displayed on another device
WO2001084433A1 (fr) * 2000-05-01 2001-11-08 Mobliss, Inc. Systeme permettant de conduire des enquetes electroniques

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO0193094A1 *

Also Published As

Publication number Publication date
US20030158894A1 (en) 2003-08-21
FR2809844A1 (fr) 2001-12-07
AU2001262431A1 (en) 2001-12-11
WO2001093094A1 (fr) 2001-12-06
FR2809844B1 (fr) 2002-11-22

Similar Documents

Publication Publication Date Title
EP1285361A1 (fr) Systeme de publication multi-terminal et procede de mise en oeuvre correspondant
US10747505B1 (en) API specification generation
Wielemaker et al. SWI-Prolog and the web
US8640087B2 (en) Semantic system for integrating software components
KR101004576B1 (ko) 연쇄 발견 웹 서비스
Frischmuth et al. Ontowiki–an authoring, publication and visualization interface for the data web
US20060206883A1 (en) Semantic system for integrating software components
US20040187111A1 (en) Content management portal and method for communicating media content
EP1444611A2 (fr) Interface graphique de portail web semantique
Binding et al. KOS at your service: Programmatic access to knowledge organisation systems
US20120180073A1 (en) Mobile Device Application Framework
Alarcon et al. REST web service description for graph-based service discovery
US20150149887A1 (en) Method of implementing structured and non-structured data in xml document
FR2841998A1 (fr) Procede d&#39;execution sur une station d&#39;un reseau de communication d&#39;un programme informatique represente dans un langage de balisage
Nachouki et al. MashUp web data sources and services based on semantic queries
Lanthaler et al. Seamless integration of restful services into the web of data
Meroño-Peñuela et al. Web data APIS for knowledge graphs: easing access to semantic data for application developers
US7032167B1 (en) Method and apparatus for a document parser specification
He et al. F2R: Publishing file systems as Linked Data
JP2003242127A (ja) 業務統合システム
EP1285360B1 (fr) Module de creation d&#39;objets, a partir de donnees brutes extraites d&#39;au moins une source de donnees contenant au moins un document exprime selon un langage de type &#34;markup&#34;
Bergweiler A flexible framework for adaptive knowledge retrieval and fusion for kiosk systems and mobile clients
Hakimjavadi et al. SW-MIS: A Semantic Web based model for integration of institutional repositories metadata records
US7240126B1 (en) Method and system for parsing for use in a server and web browser
Daly et al. Toward a Reference Architecture for Digital and Model-Based Engineering Information Systems

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20021127

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

RIN1 Information on inventor provided before grant (corrected)

Inventor name: ZISERMAN, FRANEOIS

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20041201