EP1869548A2 - Synchronisation de donnees - Google Patents

Synchronisation de donnees

Info

Publication number
EP1869548A2
EP1869548A2 EP06725635A EP06725635A EP1869548A2 EP 1869548 A2 EP1869548 A2 EP 1869548A2 EP 06725635 A EP06725635 A EP 06725635A EP 06725635 A EP06725635 A EP 06725635A EP 1869548 A2 EP1869548 A2 EP 1869548A2
Authority
EP
European Patent Office
Prior art keywords
data
objects
exchanged
export
version
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
EP06725635A
Other languages
German (de)
English (en)
Inventor
Ronald Lange
Thomas Banik
Rainer Bitzer
Rainer Heller
Peter Niederhuber
Rudolf Pohlan
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.)
Siemens AG
Original Assignee
Siemens AG
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 Siemens AG filed Critical Siemens AG
Publication of EP1869548A2 publication Critical patent/EP1869548A2/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/80—Information retrieval; Database structures therefor; File system structures therefor of semi-structured data, e.g. markup language structured data such as SGML, XML or HTML
    • G06F16/84—Mapping; Conversion

Definitions

  • the invention relates to a method and a device for synchronizing data.
  • the invention has for its object to simplify the synchronization of data between applications.
  • This object is achieved by a method for the synchronization of data between applications, in which the data is at least partially exchanged between the applications, whereby the exchanged data is synchronized with data present in the respective application, the data being marked for incompleteness is assigned.
  • This object is achieved by a system for the synchronization of data between applications, wherein data is at least partially interchangeable between the applications, wherein synchronization means are provided for synchronizing the exchanged data with existing data in the respective application, wherein the data can be assigned an identification for an incompleteness is.
  • XML has become the basic description language for structured data exchange. However, XML does not provide sufficient specifications to handle the above mentioned. Fully support the scenario. First further definitions were made in the PNO specification XMLgPROFIBUS (object model, management of foreign keys, multilingualism, ).
  • the invention addresses the change management in data exchange. These are u.a. the following use cases that can not be adequately supported by XML alone:
  • a root object can typically be selected, from which all objects are exported. additionally Filter settings can still be defined so that not all object data is always exported. o How can recognize the importing application, wel ⁇ ches root object or which filter settings were selected overall? o How can the resulting export files still be described using a uniform XML schema?
  • PROFIBUS Guideline XML @ PROFIBUS addresses change management only unzurei ⁇ accordingly.
  • the present invention relates in the exporting ⁇ approximately examples in part on the fenen in this guideline getrof ⁇ specifications.
  • This marking is also referred to as partial labeling.
  • the identification is advantageously hierarchically assignable and / or inheritable.
  • An exporting application can define whether to perform a full or partial export. There are several scenarios for a partial export:
  • Each object in an export file can have an optional attribute PartialExport, with the possible values being true or false.
  • This attribute refers to the Whether ⁇ ject itself and aggregated to all its sub-elements, if not a subobject his own PartialExport attribute sitting be ⁇ . At the root object, the attribute has a default value of true.
  • PartialExport of an object is false (either because it is explicitly specified in the object or because it is "inherited" by its parent), then the importing application must assume that the file contains all the subelements of that object exists and contains additional subobjects that are not in the import files are found, they should be considered deleted. In most cases, the importing application does not automatically delete its internal object in such a scenario, but asks the user for confirmation.
  • PartialExport true the importing application processes all sub-objects, gene of the products contained in the import file ⁇ , and allows additional subobjects which it may have in their ternal in ⁇ data unchanged.
  • This example means:
  • o ObjectA has a child ObjectBl and can also have other child objects o ObjectB has exactly the child objects ObjectCl and ObjectDl and no other child objects.
  • an object type "dynamic Attribu ⁇ te" exhibit, ie attributes that can be present in an instance of that type or not and possibly even added during the lifetime of an instance or deleted.
  • an object which is a "Settings” feature with such attributes ent holds ⁇
  • an optional "PartialAttribute” attribute include. Just like the PartialExport attribute refers this Att ⁇ ribut to the object itself and on all of its aggregated sub-elements, if not a subobject his own partial Attributes attribute owns. At the root object that has Att ⁇ ribut a default value of "true”.
  • PartialAttributes is false, the importing application assumes that the import file contains all the attributes of the object. If the object already exists and contains additional dynamic attributes, they should be seeks as deleted be ⁇ .
  • the import ⁇ de application processes all attributes that are present in the import file, and allows additional attributes it may have in their ternal in ⁇ object unchanged.
  • PartialAttributes is irrelevant to attributes that are not dy ⁇ cally are (which are always present in the object instance and can not be deleted).
  • the importing application can always static attributes unchanged when the Attrib ⁇ but not present in the import file.
  • PartialExport or PartialAttributes If an exporting application sets PartialExport or PartialAttributes to "true", it must have a way to specify that an object or attribute should be deleted by importing (simply not importing the deleted object is sufficient) not enough, the importing application would just leave its internal data unchanged).
  • every object and every dynamic attribute can have a "Deleted" attribute.
  • the deleted flag is set for an object or attribute, it is not necessary to write the full content of the element to the export file. However, it must be possible for the importing application to identify the object or attribute to be deleted, so that, for example, the name and / or the idea of an object should be specified; like any application-specific identifiers that may be present.
  • the importing application should also consider the corresponding object or attribute deleted. This use is per ⁇ not recommended that the exporting application should simply not export the corresponding element to specify that it was deleted.
  • the user may choose to either export a complete project or just a sub-tree.
  • a root object in the tree view can select a root object in the tree view and start an export of this object and its subelements via a (context) menu.
  • a (context) menu Is not normally ever ⁇ the object in a project hierarchy as the root object meaningful ⁇ full, it should only specific types can be selected for this purpose.
  • the parent objects of the selected root object should also be written to the export file as "shell objects".
  • This document does not define a mechanism for formulating such filters. It is left to export the application to determine whether, for example filters are fixed or can be defined by the user or whether a filter is a "posi- tive list” exportable types or a "negative list” ge ⁇ -filtered types.
  • Fig. 4 gives an example of the different ways to restrict an export.
  • An XML schema file plays in the overall export / import process.
  • An XSD file can have two different purposes:
  • a schema (and the schema fragments shown throughout the present document) has the main purpose of describing the XML format.
  • the fact that the instance files can be validated on the basis of such a scheme is secondary - this alone will not guarantee that the instance may be he ⁇ successfully imported.
  • a compatible change is, for example, the addition of elements or attributes to existing objects. Incompatible changes include deleting or renaming attributes or structural changes.
  • the version number of the schema he ⁇ should höht (typically mer to the next Hauptversionsnum-).
  • a single XML instance file can combine elements from different versions, that is, from different namespaces. This allows an importing application - which is not necessarily interested in the full file - to determine if it is affected by an incompatible change. Theoretically, this mechanism can be used individually for each element type. However, it is recommended to use it only on the granularity of possible root objects for export.
  • the format for the ObjectB subobject is changed incompatible, but the rest of the XML format (for objects A, C, and so on) remains unchanged. It may be useful to use only an updated namespace for the subtree starting with ObjectB. This may be reasonable if it is likely that export files will not contain instances of ObjectB (if it is an optional element) or import clients that ObjectB does not care about.
  • ⁇ Document xmlns "http: // www. Siemens.com/automation / 04/12 / SimaticML / SW"
  • Fig. 5 shows an example.
  • the version number of the XML format is increased (typically to the next minor version number), the name space remains unchanged.
  • the version number is part of the document header in each instance file as well as an XML schema file:
  • the importing application can determine how to perform the import.
  • the application can rest assured that the file contains all the expected elements in it ⁇ waited format, but must come to be prepared to compatible enhancements (additional eg elements or attributes)
  • every object in an XML export file can carry an optional version attribute.
  • an exporting application can write the "project version number" of this object in the internal data representation.
  • XML format for instances of the same type in the same file must be the same (that is, the same schema), even if their data version is different.
  • an XML always export an export file that corresponds to a specific version, even if the internal data representation can contain objects of different versions.
  • Certain objects may additionally carry "version information", e.g., something like “firmware version” or a version number specified by the user. From the standpoint of export / import and XML format, such an attribute is treated just like any other object attribute (such as a comment field) and is stored in the object's "settings" feature.
  • version information e.g., something like "firmware version” or a version number specified by the user.
  • An export file may only contain parts of a project. That is why it is possible that a relation an exported object to an object that is not part of the export.
  • the importing application When importing an external reference, the importing application must be able to correctly resolve the reference, especially if
  • the target object As “envelope object” is exported, that is, it is written as a "placeholder” without its contents (attitudes, child objects and wider at ⁇ relations) in the export file.
  • envelope object Such a shell object maintains its full name hierarchy in a "path" attribute in addition to the local name (so that the importing application has access to the full name hierarchy).
  • each relation writes its own shell object. Have these shell objects its own unique ID (to ensure that the ID within ei ⁇ ner file is unique), but refer to the same target object (ie, point to the same name, path and the same Appld 's).
  • the invention thus relates to a method and a system for the synchronization of data between applications, in which the data is at least partially exchanged between the applications, the exchanged data being synchronized with data present in the respective application.
  • an incomplete tag be mapped to the data.

Landscapes

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

Abstract

L'invention concerne un procédé et un système de synchronisation de données entre des applications. Les données sont échangées, au moins en partie, entre des applications. Les données échangées sont synchronisées avec les données présentes dans l'application en question. Pour simplifier la synchronisation, on propose d'affecter aux données une identification d'incomplétude.
EP06725635A 2005-04-11 2006-04-07 Synchronisation de donnees Withdrawn EP1869548A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102005016690A DE102005016690A1 (de) 2005-04-11 2005-04-11 Synchronisation von Daten
PCT/EP2006/061423 WO2006108801A2 (fr) 2005-04-11 2006-04-07 Synchronisation de donnees

Publications (1)

Publication Number Publication Date
EP1869548A2 true EP1869548A2 (fr) 2007-12-26

Family

ID=36617332

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06725635A Withdrawn EP1869548A2 (fr) 2005-04-11 2006-04-07 Synchronisation de donnees

Country Status (4)

Country Link
US (1) US8032893B2 (fr)
EP (1) EP1869548A2 (fr)
DE (1) DE102005016690A1 (fr)
WO (1) WO2006108801A2 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090144610A1 (en) * 2007-06-14 2009-06-04 Aristocrat Technologies Australia Pty. Limited Translating xml with multiple namespace extensions
CN102143193B (zh) * 2010-01-29 2014-01-22 国际商业机器公司 用于数据同步的方法和系统
US9038024B2 (en) * 2012-09-07 2015-05-19 Sap Se Development of process integration scenarios on mobile devices

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7149813B2 (en) 2001-08-14 2006-12-12 Microsoft Corporation Method and system for synchronizing mobile devices
US7836103B2 (en) * 2002-11-18 2010-11-16 Siebel Systems, Inc. Exchanging project-related data between software applications
US7308458B2 (en) * 2003-06-11 2007-12-11 Wtviii, Inc. System for normalizing and archiving schemas
US7620658B2 (en) * 2003-09-24 2009-11-17 Microsoft Corporation Configuration of a directory system
US7882146B2 (en) * 2003-12-01 2011-02-01 Microsoft Corporation XML schema collection objects and corresponding systems and methods
US7757220B2 (en) * 2004-10-21 2010-07-13 Discovery Machine, Inc. Computer interchange of knowledge hierarchies

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
WO2006108801A2 (fr) 2006-10-19
DE102005016690A1 (de) 2006-10-12
WO2006108801A3 (fr) 2007-05-10
US8032893B2 (en) 2011-10-04
US20090217312A1 (en) 2009-08-27

Similar Documents

Publication Publication Date Title
EP1258812B1 (fr) Base de données virtuelle de structures de données hétérogènes
DE60002876T2 (de) Darstellung, verwaltung und synthese von technischen inhalten
DE10308725A1 (de) System und Verfahren zum Verwalten und zum Austausch von Daten eines technischen Projektes, einer technischen Anlage sowie einzelner Anlagenkomponenten
EP1638028A2 (fr) Génération assistée par ordinateur et gestion de changement pour interfaces utilisateur
EP1559031A2 (fr) Evolution de schema compatible en amont et en aval
DE102012001406A1 (de) Automatische Konfiguration eines Produktdatenmanagementsystems
WO2006108801A2 (fr) Synchronisation de donnees
EP1202166B1 (fr) Système pour la verification de modèles de logiciels dans chaines d'outils pour developpement de logiciel
DE102016005519B4 (de) Verfahren zur Erstellung eines Metadaten-Datenmodells für eine BI-Infrastruktur
DE4308291C2 (de) Verfahren und Vorrichtung zur vorgangsbezogenen Erstellung und Bearbeitung von Dokumenten
EP1515207A1 (fr) Objet d'automatisation et méthode pour la description d'un objet d'automatisation en utilisant une métalangage
DE102010064167A1 (de) Dynamische Berichtserstellung
Pietranek Datenmanagementpatterns in multi-skalaren Simulationsworkflows
EP1285315B1 (fr) Systeme de traitement d'informations et son procede d'exploitation
WO2000007116A1 (fr) Procede, dispositif et jeu de dispositifs pour l'elimination d'au moins une inconsistance dans un ensemble de banques de donnees comportant une banque de donnees et au moins une banque de donnees de copie de ladite banque de donnees
EP1234231B1 (fr) Procede permettant de produire des interfaces utilisateur graphiques pour des programmes informatiques
DE102010010035A1 (de) Verfahren zum Erstellen von Objekten einer objektorientierten Datenbank
EP1556789A1 (fr) Gestion de donnees decrites au moyen d'un langage de balisage extensible
Finkes A hierarchical Eclipse-based editor for system dependency graphs
DE10109876B4 (de) Verfahren und Einrichtung zum Datenmanagement
Moos XQuery und SQL/XML in DB2-Datenbanken
DE19858163A1 (de) Verfahren zum Übertragen von Informationen zwischen Datenbeständen Client-Applikationen
EP3770769A1 (fr) Procédé de demande ou de traitement d'un fichier complet au moyen d'une langue de recherche et dispositif de gestion dudit procédé
EP3432139A1 (fr) Procédé implémenté par ordinateur destiné à générer du code de programme informatique
WO2004042556A2 (fr) Structuration, memorisation et traitement de donnees selon un modele objet generique

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: 20071001

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): DE FR GB IT

17Q First examination report despatched

Effective date: 20080124

RIN1 Information on inventor provided before grant (corrected)

Inventor name: LANGE, RONALD

Inventor name: NIEDERHUBER, PETER

Inventor name: BANIK, THOMAS

Inventor name: POHLAN, RUDOLF

Inventor name: BITZER, RAINER

Inventor name: HELLER, RAINER

DAX Request for extension of the european patent (deleted)
RBV Designated contracting states (corrected)

Designated state(s): DE FR GB IT

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: 20080604