EP1869548A2 - Synchronisation von daten - Google Patents
Synchronisation von datenInfo
- 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
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
Die Erfindung betrifft ein Verfahren sowie ein System zur Synchronisation von Daten zwischen Applikationen, bei welchem die Daten zumindest teilweise zwischen den Applikationen ausgetauscht werden, wobei die ausgetauschten Daten mit in der jeweiligen Applikation vorhandenen Daten synchronisiert werden. Um die Synchronisation zu vereinfachen, wird vorgeschlagen, dass den Daten eine Kennzeichnung für eine Unvollständigkeit zugeordnet wird.
Description
Beschreibung
Synchronisation von Daten
Die Erfindung betrifft ein Verfahren sowie eine Vorrichtung zur Synchronisation von Daten.
Der Erfindung liegt die Aufgabe zugrunde, die Synchronisation von Daten zwischen Applikationen zu vereinfachen.
Diese Aufgabe wird durch ein Verfahren zur Synchronisation von Daten zwischen Applikationen gelöst, bei welchem die Daten zumindest teilweise zwischen den Applikationen ausgetauscht werden, wobei die ausgetauschten Daten mit in der je- weiligen Applikation vorhandenen Daten synchronisiert werden, wobei den Daten eine Kennzeichnung für eine Unvollständigkeit zugeordnet wird.
Diese Aufgabe wird durch ein System zur Synchronisation von Daten zwischen Applikationen gelöst, wobei Daten zumindest teilweise zwischen den Applikationen austauschbar sind, wobei Synchronisationsmittel zur Synchronisierung der ausgetauschten Daten mit in der jeweiligen Applikation vorhandenen Daten vorgesehen sind, wobei den Daten eine Kennzeichnung für eine Unvollständigkeit zuordenbar ist.
In der Engineeringkette von der Produkt- bis zur Anlagenpla¬ nung und Anlagenautomatisierung gibt es Übergänge zwischen verschiedenen Datenhaltungen. Dies ist zum einen technisch bedingt, da es (auch in Zukunft) nicht eine Produktsuite ge¬ ben wird, die alle Aspekte integriert anbietet . Zum anderen ist dies durch die verschiedenen Anwender-Rollen innerhalb der Engineeringkette bedingt, die durchaus zeitweise unsyn- chronisiert arbeiten möchten und zu definierten Zeitpunkten einen Abgleich mit den Datenhaltungen der anderen Anwender- Rollen durchführen möchten. Dabei ist es wichtig, dass eine Änderung potenziell von allen Anwender-Rollen durchgeführt
werden kann, der Abgleich der Datenhaltungen muss also prinzipiell bi- oder multidirektional erfolgen können.
Als Basis-Beschreibungssprache für den strukturierten Daten- austausch hat sich XML durchgesetzt. Allerdings bietet XML keine ausreichenden Festlegungen, um das o.g. Szenario vollständig zu unterstützen. Erste weitergehende Festlegungen wurden in der PNO Spezifikation XMLgPROFIBUS getroffen (Objektmodell, Verwaltung von Fremdschlüsseln, Mehrsprachigkeit, ... ) .
Die Erfindung adressiert insbesondere das Änderungsmanagement beim Datenaustausch. Dies sind u.a. folgende Use Cases, die durch XML alleine nicht ausreichend unterstützt werden kön- nen :
o Falls die Datenhaltungen schon einmal synchronisiert wur¬ den, sollten bei späteren Synchronisationen nur die Änderungen ausgetauscht werden. o Wie kann man die Änderungen auf die bereits ausge¬ tauschten Projektdaten beziehen? o Wie können Löschungen übermittelt werden? o Wie können Objektpfade übergeben werden, ohne die Ob¬ jektdaten zu duplizieren?
o Die Modelle der verschiedenen Datenhaltungen sind typischerweise nicht deckungsgleich. Daher kann eine Datenhal¬ tung nur unvollständige Information für andere Datenhal¬ tungen liefern. o Wie wird diese Unvollständigkeit ausgedrückt? Insbe¬ sondere wie wird unterschieden, dass ein Datum in Austausch nicht vorhanden ist, weil es die exportie¬ rende Datenhaltung nicht kennt oder weil das Datum gelöscht wurde?
o Beim Export kann typischerweise ein Root-Objekt ausgewählt werden, ab dem alle Objekte exportiert werden. Zusätzlich
können noch Filtereinstellungen definiert werden, dass nicht immer alle Objektdaten exportiert werden. o Wie kann die importierende Applikation erkennen, wel¬ ches Root Objekt bzw. welche Filtereinstellungen ge- wählt wurden? o Wie können die entstehenden Exportdateien trotzdem über ein einheitliches XML-Schema beschrieben werden?
o Die Datenschemas der Datenhaltungen können sich ändern. o Wie kann beim Import von Datenhaltungen festgestellt werden, ob Änderungen des Datenschemas vorliegen? Wenn ja, welcher Art (kompatibel, inkompatibel, nur objektbezogen, ... ) ?
Die Spezifikation PROFIBUS Guideline XMLgPROFIBUS (PNO Order No. 2.342) adressiert das Änderungsmanagement nur unzurei¬ chend. Die vorliegende Erfindung bezieht sich in den Ausfüh¬ rungsbeispielen teilweise auf die in dieser Guideline getrof¬ fenen Festlegungen.
Die vorliegende Erfindung und deren vorteilhaften Ausgestal¬ tungen lösen die oben angegebenen Fragestellungen. Die in der Beschreibung angegebene konkrete XML-Syntax ist als Ausfüh¬ rungsbeispiel zu verstehen, die Erfindung ist davon natürlich unabhängig. Die Erfindung bzw. die vorteilhaften Ausgestaltungen der Erfindung enthalten u. a. folgende Konzepte:
o Kennzeichnung für die Unvollständigkeit von exportierten
Objekten und Attributen. Diese Kennzeichnung wird auch als Partial Kennzeichnung bezeichnet. Die Kennzeichnung ist vorteilhafterweise hierarchisch zuordenbar und/oder vererbbar .
o Konzept von Hüllobjekten (shell objects) , die zwar alle zur Idenfikation nötigen Attribute (Name, ID) tragen, jedoch nicht als vollwertige Objekte übertragen werden. Ba¬ sis kann hier insbesondere eine Namenshierarchie sein.
o Versionierungskonzept (über XML-Schemaversion, XML- Namespace und Data version) , dass beim Import einer Daten¬ haltung die Art der Datenänderungen erkannt werden kann und generisch darauf reagiert werden kann. Dadurch ist in den meisten Fällen eine Änderung eines Datenschemas einer exportierenden Applikation möglich, ohne dass die Importroutinen der anderen Datenhaltungen geändert werden müssen. Vorteilhafterweise wird eine mehrschichtige Kenn- Zeichnung der Version verwendet.
Nachfolgend wird die Erfindung anhand der in den Figuren dargestellten Ausführungsbeispiele näher beschrieben und erläu¬ tert.
Es zeigen:
FIG 1 eine prinzipielle Darstellung einer Engineeringket¬ te,
FIG 2 ein Ablaufdiagramm zur Darstellung des Imports von Daten,
FIG 3 ein Ablaufdiagramm zur Darstellung der Zusammenfüh- rung von Objekten,
FIG 4 verschiedene Möglichkeiten der Restriktion bei einem Export von Daten,
FIG 5 ein Beispiel für Namenshierarchien und
FIG 6 ein Beispiel für externe Referenzen.
Eine exportierende Applikation kann definieren, ob sie einen vollen oder einen teilweisen Export durchführt. Es gibt mehrere Szenarien für einen teilweisen Export:
o Eine Applikation, die Änderungen seit einem vorherigen Export verfolgen kann, könnte sich entscheiden, nur diese „Delta-Informationen" zu exportieren, d.h. nur die neuen oder editierten Objekte und Attribute zu exportie¬ ren .
o Einer externen Applikation könnten möglicherweise nicht alle Daten zur Verfügung stehen, die eine importierende Applikation erwartet (z.B. aufgrund von Objektmodelldis¬ krepanzen) , so dass sie den Export als teilweise markie- ren würde.
o Wenn eine Applikation nicht ihr vollständiges Projekt sondern nur einen Subbaum exportiert, dann sind die ü- bergeordneten Objekte des Wurzelobjekts (die als Hüllob- jekte exportiert werden) definitionsgemäß teilweise. Dasselbe gilt für etwaige Zielobjekte externer Referen¬ zen, die existieren können.
Jedes Objekt in einer Exportdatei kann ein optionales Attri- but PartialExport aufweisen, wobei die möglichen Werte „true" oder „false" sind. Dieses Attribut bezieht sich auf das Ob¬ jekt selbst und auf alle seine aggregierten Subelemente, wenn nicht ein Subobjekt sein eigenes PartialExport-Attribut be¬ sitzt. An dem Wurzelobjekt hat das Attribut einen Vorgabewert von „true".
Wenn PartialExport eines Objekts false ist (weil es entweder explizit in dem Objekt spezifiziert wird oder weil es von seinem übergeordneten Objekt „geerbt" wird) , muss die impor- tierende Applikation annehmen, dass die Datei alle Subelemente dieses Objekts enthält. Wenn das Objekt bereits existiert und zusätzliche Subobjekte enthält, die nicht in der Import-
datei zu finden sind, sollten sie als gelöscht betrachtet werden. In den meisten Fällen löscht die importierende Applikation ihr internes Objekt in einem solchen Szenario nicht automatisch, sondern erfragt vom Benutzer Bestätigung.
Wenn PartialExport true ist, verarbeitet die importierende Applikation alle Subobjekte, die in der Importdatei vorlie¬ gen, und lässt zusätzliche Subobjekte, die sie in ihren in¬ ternen Daten aufweisen kann, unverändert.
Beispiel-Instanz-Fragment :
<ObjectA ID="1" PartialExport="true" >
<ObjectB ID="2" Name="ObjectBl" PartialExport="false"> <ObjectC ID="3" Name="0bjectCl" />
<ObjectD Name="ObjectDl" ID="4" /> </ObjectB> </ObjectA>
Dieses Beispiel bedeutet:
o ObjectA besitzt ein untergeordnetes ObjectBl und kann außerdem weitere untergeordnete Objekte aufweisen o ObjectB besitzt genau die untergeordneten Objekte Ob- jectCl und ObjectDl und keine weiteren untergeordneten Objekte .
In bestimmten Fällen kann ein Objekttyp „dynamische Attribu¬ te" aufweisen, d.h. Attribute, die in einer Instanz dieses Typs präsent sein können oder auch nicht und die möglicherweise sogar während der Lebenszeit einer Instanz hinzugefügt oder gelöscht wurden. Bei einem solchen Szenario kann ein Objekt (das ein „Settings"-Merkmal mit solchen Attributen ent¬ hält) ein optionales Attribut „PartialAttribute" aufweisen. Genau wie das PartialExport-Attribut bezieht sich dieses Att¬ ribut auf das Objekt selbst und auf alle seine aggregierten Subelemente, wenn nicht ein Subobjekt sein eigenes Partial-
Attributes-Attribut besitzt. An dem Wurzelobjekt hat das Att¬ ribut einen Vorgabewert von „true".
Wenn PartialAttributes false ist, nimmt die importierende Ap- plikation an, dass die Importdatei alle Attribute des Objekts enthält. Wenn das Objekt bereits existiert und zusätzliche dynamische Attribute enthält, sollten sie als gelöscht be¬ trachtet werden.
Wenn PartialAttributes true ist, verarbeitet die importieren¬ de Applikation alle Attribute, die in der Importdatei präsent sind, und lässt zusätzliche Attribute, die sie in ihrem in¬ ternen Objekt aufweisen kann, unverändert.
PartialAttributes ist für Attribute irrelevant, die nicht dy¬ namisch sind (die immer in der Objektinstanz präsent sind und nicht gelöscht werden können) . Die importierende Applikation lässt statische Attribute immer unverändert, wenn das Attri¬ but nicht in der Importdatei präsent ist.
Beispiel :
<ObjectB ID="2" Name="ObjectBl">
<Settings PartialAttributes="true" > <Propertyl>ll</Propertyl>
<Property2>0.5</Property2> <Property3>3</Property3> </Settings>
<ObjectC ID="3" Name="ObjectCl"> <Settings>
<PropertyA>ll</PropertyA> <PropertyB>0.5</PropertyB> </Settings> </ObjectC> </ObjectB>
o ObjectB hat die Eigenschaften 1, 2 und 3 und möglicherweise weitere Attribute o ObjectC hat genau die Eigenschaften A und B und keine anderen (dynamischen) Attribute.
Wenn eine exportierende Applikation PartialExport oder Parti- alAttributes auf „true" setzt, muss sie über eine Möglichkeit verfügen, zu spezifizieren, dass ein Objekt oder Attribut durch den Import gelöscht werden sollte. (Einfach nur das ge- löschte Objekt nicht zu importieren, reicht nicht aus; die importierende Applikation würde einfach nur ihre internen Daten unverändert lassen) .
Zu diesem Zweck kann jedes Objekt und jedes dynamische Attri- but ein „Deleted"-Attribut führen.
Dieses Flag wird für Objekte durch XML@Profibus, aber nicht für Attribute definiert. Wenn eine Applikation dynamische Attribute aufweist (die löschbar sind) , muss das Schema ent- sprechende Typen deklarieren, wie in dem folgenden Beispiel:
Instanz :
<ObjectA ID="1" PartialExport="true" > <ObjectB ID="2" Name="0bjectBl">
<Settings PartialAttributes="true"> <Propertyl Deleted="true" /> <Property2>0.6</Property2> </Settings> </ObjectB>
<ObjectC ID="3" Name="ObjectCl" Deleted="true" /> </ObjectA>
Schema :
<xsd: complexType name="ObjectBSettingsFeatureT">
<xsd: complexContent> <xsd: extension base="prim:FeatureT"> <xsd: sequence> <xsd: element name="Propertyl" type="Deletable_integer" minθccurs=" 0 " />
<xsd: element name="Property2" type="xsd: double" minOccurs="0"/>
<xsd: element name="Property3" type="xsd: integer minθccurs=" 0 " /> </xsd: sequence> </xsd: extension> </xsd: complexContent> </xsd: complexType>
<xsd: complexType name="Deletable_integer"> <xsd: simpleContent>
<xsd: extension base="xsd: integer"> <xsd: attribute name="Deleted" type="xsd:boolean" use="optional" default="false" /> </xsd: extension> </xsd: simpleContent> </xsd: complexType>
Wenn dieses Attribut auf „true" gesetzt wird, sollte die im¬ portierende Applikation das entsprechende Objekt oder Attri¬ but als gelöscht betrachten. Wenn das Objekt/Attribut nicht in der importierenden Applikation existiert, kann es igno- riert werden.
Wenn das Deleted-Flag für ein Objekt oder Attribut gesetzt ist, ist es nicht notwendig, den vollen Inhalt des Elements in die Exportdatei zu schreiben. Es muss jedoch für die im- portierende Applikation möglich sein, das zu löschende Objekt oder Attribut zu identifizieren, so dass z.B. der Name und/oder die Idee eines Objekts angegeben werden sollte, so-
wie etwaige applikationsspezifische Kennungen, die präsent sein können.
Wenn das Deleted-Flag in Verbindung mit auf false gesetztem PartialExport/PartialAttributes verwendet wird, sollte die importierende Applikation auch das entsprechende Objekt oder Attribut als gelöscht betrachten. Diese Verwendung wird je¬ doch nicht empfohlen, die exportierende Applikation sollte einfach nur das entsprechende Element nicht exportieren, um zu spezifizieren, dass es gelöscht wurde.
In vielen Szenarien kann der Benutzer wählen, entweder ein vollständiges Projekt oder nur einen Subbaum zu exportieren. In der Regel kann er ein Wurzelobjekt in der Baumansicht wäh- len und einen Export dieses Objekts und seiner Subelemente über ein (Kontext-) Menü starten. Normalerweise ist nicht je¬ des Objekt in einer Projekthierarchie als Wurzelobjekt sinn¬ voll, es sollten nur spezifische Typen für diesen Zweck gewählt werden.
Um sicherzustellen, dass die importierende Applikation Zugang zu den vollständigen Kontextinformationen (d.h. der Namenhierarchie) besitzt, sollten auch die übergeordneten Objekte des gewählten Wurzelobjekts als „Hüllobjekte" in die Export- datei geschrieben werden.
<Document xmlns="http : //www. siemens . com/automation/SimaticML">
<ObjectA ID="1" Shellθbject="true"> <ObjectB ID="2" Name="0bjectBl">
<Settings>
<AttributeA>ll</AttributeA> <AttributeB>some content</AttributeB> <AttributeC>0.5</AttributeC> </Settings>
</ObjectB> </ObjectA>
</Document>
Zusätzlich zu der Einschränkung eines Exports über „Par- tialExport" oder dem Exportieren nur eines Subbaums kann es auch möglich sein, ein „Filter" auf einen Export anzuwenden. Im Prinzip bedeutet dies, dass nur Objekte spezifischer Typen in die XML-Datei geschrieben werden. Um ein solches „Filter" zu bezeichnen, kann das Projektelement ein „ExportScope"- Attribut führen.
Dieses Dokument definiert keinen Mechanismus zum Formulieren solcher Filter. Es wird der exportierenden Applikation überlassen, zu bestimmen, ob z.B. Filter fest sind oder vom Benutzer definiert werden können oder ob ein Filter eine „Posi- tiv-Liste" exportierbarer Typen oder eine „Negativ-Liste" ge¬ filterter Typen ist.
Vom Standpunkt des XML-Formats aus gesehen ist es nur wich¬ tig, dass das ExportScope-Attribut einen „Filter Name" ent- hält und dass die exportierende und importierende Applikation sich ein gemeinsames Verständnis über die durch diesen Namen beschriebenen Filtereigenschaften teilen.
Fig. 4 gibt ein Beispiel für die verschiedenen Möglichkeiten zum Einschränken eines Exports.
Obwohl jedes XML-Format mit Langzeitstabilität als Ziel ent¬ wickelt werden sollte, ist es praktisch unausweichlich, dass ein Format möglicherweise während des Lebenszyklus eines Pro- dukts oder einer Komponente verändert werden muss. Die nach¬ folgend in diesem Kapitel beschriebenen Mechanismen können dabei helfen, dass eine solche Änderung handhabbar wird, es sollte jedoch beachtet werden, dass Widerstand gegen Format¬ änderungen hauptsächlich eine Frage der „robusten Implemen- tierung" eines Importmechanismus ist.
Wenn zum Beispiel eine importierende Applikation während des Analysierens einer XML-Datei auf ein unbekanntes Element stößt, könnte sie zum Beispiel das Element falls möglich auf generische Weise behandeln, oder sie könnte wählen, es ein- fach zu ignorieren (und eine Warnung an den Benutzer auszugeben) . Sie darf aber in einer solchen Situation auf keinen Fall abstürzen und sollte den Importprozess nicht abbrechen.
Wenn eine importierende Applikation ein erwartetes Element oder Attribut beim Analysieren einer XML-Datei nicht findet, sollte sie ähnlich versuchen, statt dessen Vorgabewerte zu verwenden .
Die genauen Anforderungen für die Versionierung einer Import- Export-Funktionalität können für jede Anwendung unterschied¬ lich sein, in der Regel ist es jedoch erwünscht, dass eine Anwendung nicht nur aktuelle XML-Dateien importieren kann, sondern auch Dateien, die einer vorherigen Version des XML- Formats entsprechen.
Ein bemerkenswerter Punkt ist die Rolle, die eine XML- Schemadatei in dem Gesamtexport-/-importprozess spielt. Eine XSD-Datei kann zwei verschiedene Zwecke aufweisen:
o Sie kann als eine Dokumentation eines Exportformats die¬ nen. Durch Bereitstellung eines Schemas kann die exportierende Applikation beschreiben, welche Art von XML- Instanzdateien sie erzeugt. Solche Dokumentation könnte auch als unstrukturierte Prosa bereitgestellt werden; die Verwendung von XSD hat den Vorteil einer formalen Sprache zur Beschreibung des Formats. Die Hauptadressa¬ ten dieses XSD sind ein menschlicher Leser, der normalerweise auch die Semantik des Formats verstehen muss, o Mit einer XSD-Datei kann man eine Menge von Anweisungen anhand einer XML-Instanzdatei prüfen. XSD ist nur eine Sprache zur Formulierung solcher Anweisungen (andere sind RelaxNG, Schematron oder sogar reguläre Ausdrücke) .
Welche Anweisungen anhand einer spezifischen XML-Instanz getestet werden müssen, kann von dem Verbraucher der Instanz abhängen und kann sogar über die Verarbeitungskette des Verbrauchers hinweg variieren.
Im Kontext eines Export/Import hat ein Schema (sowie die im Verlauf des gesamten vorliegenden Dokuments gezeigten Schema- Fragmente) hauptsächlich den Zweck des Beschreibens des XML- Formats. Die Tatsache, dass die Instanzdateien auch anhand eines solchen Schemas validiert werden können, ist sekundär - dadurch alleine wird nicht garantiert, dass die Instanz er¬ folgreich importiert werden kann.
Änderungen an einem XML-Format können als „kompatibel" oder „inkompatibel" klassifiziert werden. Die Begriffe „kompati¬ bel" und „inkompatibel" werden im Folgenden wie in /XMLPB/ definiert verwendet. Eine kompatible Änderung ist z.B. das Hinzufügen von Elementen oder Attributen zu existierenden Objekten. Inkompatible Änderungen sind z.B. Löschen oder Umbe- nennen von Attributen oder strukturelle Änderungen.
Wenn eine Applikation ihr XML-Format auf inkompatible Weise ändern muss, sollte sie den Namenraum ändern, um explizit die Kompatibilität mit dem vorherigen Format zu brechen. Für die- sen Zweck ist Monat und Jahr der Schema-Version Teil des Namenraums .
Gleichzeitig sollte auch die Versionsnummer des Schemas er¬ höht werden (typischerweise auf die nächste Hauptversionsnum- mer) .
Eine einzige XML-Instanzdatei kann Elemente von verschiedenen Versionen, d.h. von verschiedenen Namenräumen kombinieren. Dies erlaubt einer importierenden Applikation - die nicht un- bedingt an der vollständigen Datei interessiert ist - zu bestimmen, ob sie durch eine inkompatible Änderung betroffen wird.
Theoretisch kann dieser Mechanismus für jeden Elementtyp einzeln verwendet werden. Es wird jedoch empfohlen, ihn nur auf der Granularität der möglichen Wurzelobjekte für einen Export zu verwenden.
Beispiel 1 :
In dem folgenden Beispiel ist eine inkompatible Änderung in dem Format für ObjectA aufgetreten und daher wurde der Namenraum aktualisiert. Das Format für das Subobjekt ObjectB ist jedoch unverändert. Da ObjectB auch als ein Wurzelobjekt für einen teilweisen Export verwendet werden kann, ist ein solcher teilweiser Export immer noch mit der vorherigen Version kompatibel. Deshalb kann es sinnvoll sein, den Namenraum für ObjectB (und alle seine Subelemente) unverändert zu lassen. Vollständiger Export:
<Document xmlns="http : //www. siemens . com/automation/05/02/SimaticML/SW"
xmlns : vθl="http : //www. siemens . com/automation/04/12/SimaticML/ SW">
<ObjectA ID="1"> (...)
<v01:ObjectB ID="2" Name="0bjectBl">
(...)
</v01:ObjectB> </ObjectA> </Document>
Export of sub-tree ObjectB:
<Document xmlns="http : //www. siemens . com/automation/04/12/SimaticML/SW">
<ObjectB ID="2" Name="ObjectBl"> (...)
</ObjectB> </Document>
Wenn die übergeordneten Objekte des relevanten Subbaums als Shell-Objekte exportiert werden (was typischerweise der Fall ist) , sollten diese Shell-Objekte auch in dem ursprünglichen Namenraum abgelegt werden. Andernfalls könnte sie möglicher¬ weise eine importierende Applikation nicht erkennen und wäre nicht in der Lage, zu dem relevanten Subbaum (ObjectB in dem Beispiel) zu navigieren
<Document xmlns="http : //www. siemens . com/automation/04/12/SimaticML/SW"> <ObjectA ID="1" Shellθbject="true" > <ObjectB ID="2" Name="ObjectBl">
(...) </ObjectB> </ObjectA> </Document>
Beispiel 2 :
In diesem Beispiel wird das Format für das Subobjekt ObjectB inkompatibel verändert, aber der Rest des XML-Formats (für die Objekte A, C usw.) bleibt unverändert. Es kann sinnvoll sein, nur einen aktualisierten Namenraum für den mit ObjectB beginnenden Subbaum zu verwenden. Dies kann vernünftig sein, wenn es wahrscheinlich ist, dass Exportdateien keine Instanzen von ObjectB enthalten (wenn es sich um ein optionales E- lement handelt) oder dass Import-Clients existieren, denen ObjectB egal ist.
<Document xmlns="http : //www. siemens . com/automation/04/12/SimaticML/SW"
xmlns : vO2="http : //www. siemens . com/automation/05/02/SimaticML/ SW">
<ObjectA ID="1">
(...)
<v02:ObjectB ID="2" Name="ObjectBl">
(...) </v02:ObjectB>
<ObjectC ID="3" >
(...)
</ObjectC> </ObjectA> </Document>
Dieser Mechanismus des Kombinierens von Namenräumen sollte vorsichtig benutzt werden, da durch ihn sowohl die Instanzda¬ teien als auch die Schemadefinitionen zunehmend komplex und weniger lesbar werden. In den meisten Fällen wirkt sich eine inkompatible Änderung auf das vollständige Format aus, so dass alle Elemente gleichzeitig zu dem neuen Namenraum verla¬ gert werden sollten.
Namenraumhierarchien:
Im Fall vernesteter Namenräume und Schemata bricht eine in¬ kompatible Änderung eines vernesteten Namenraums nicht die Kompatibilität von Instanzdateien, die dieses bestimmte Sub- System nicht benutzen. Fig. 5 zeigt ein Beispiel.
o Der Namenraum für das SW-Schema wird verändert, um Kom¬ patibilität zu brechen o Die Schema-Dateien, die das SW-Schema importieren, müs- sen angepasst werden, behalten aber ihren Namenraum
o Instanzdateien, die keine SW-relevanten Elemente enthalten, entsprechen sowohl dem alten als auch dem neuen Schema o Applikationen, die nicht an SW-bezogenen Elementen inte- ressiert sind, müssen an eine neue Version angepasst werden
Im Fall einer kompatiblen Änderung wird nur die Versionsnummer des XML-Formats erhöht (typischerweise auf die nächste Minor-Versionsnummer) , der Namenraum bleibt unverändert. Wie durch XML@Profibus definiert ist die Versionsnummer Teil des Dokumentkopfteils in jeder Instanzdatei sowie einer XML- Schemadatei :
Instanz :
<Document xmlns="http : //www. siemens . com/automation/04/12/SimaticML/SW">
<prim: Documentlnfo Version=" 0.04 "> <prim:Created Tool="PCS7" User="np" Times- tamp="2004-ll-09T08:52:37"/>
</prim: Documentlnfo>
<ObjectA ID="1">
(...) </ObjectA>
</Document> Schema:
<xsd : schema targetName- pace="http : //www. siemens . com/automation/2004/12/SimaticML" xmlns :xsd="http: //www.w3. org/2001/XMLSchema"
xmlns :prim="http : //www.profibus . com/Common/2003/ll/Primitives
II version=" 0 . 04 " >
<xsd:import names- pace="http : //www.profibus . com/Common/2003/ll/Primitives"
schemaLocation="Common-Primitives-vl .0. xsd" /> <xsd: element name="Document " type="prim:DocumentT" /> (...)
<xsd: schema>
Auf der Basis dieser Versionsnummer kann die importierende Applikation bestimmen, wie der Import durchzuführen ist.
o Wenn der Versionsnummer kleiner als die „aktuelle Versi- on" die Applikation ist, könnte sie eine Transformation aufrufen oder die Importroutinen anpassen, um das alte
Datenformat zu behandeln (es kann ausreichen, für in der
Importdatei fehlende Attribute Vorgabewerte zu liefern) .
o Wenn die Versionsnummer größer oder gleich der erwarteten Version ist, kann sich die Applikation darauf verlassen, dass die Datei alle erwarteten Elemente im er¬ warteten Format enthält, muss aber darauf vorbereitet sein, auf kompatible Erweiterungen (z.B. zusätzliche Attribute oder Elemente) zu stoßen
Gemäß XML@Profibus kann jedes Objekt in einer XML-Exportdatei ein optionales Versions-Attribut führen. Mit diesem Attribut kann eine exportierende Applikation die „Projekt-Versions- nummer" dieses Objekts in die interne Datenrepräsentation schreiben .
Dies kann besonders signifikant sein, wenn eine Applikation mehrere Versionen von Objekten in einem Projekt handhaben kann. (Eine Besprechung von Versionsmechanismen innerhalb einer Applikation und ihrer Datenrepräsentation sprengt jedoch den Rahmen dieses Dokuments) .
Es muss angemerkt werden, dass das XML-Format für Instanzen desselben Typs in derselben Datei identisch sein (d.h. demselben Schema entsprechen) muss, auch wenn ihre Datenversion unterschiedlich ist. Anders ausgedrückt erzeugt ein XML-
Export immer eine Exportdatei, die einer bestimmten Version entspricht, auch wenn die interne Datenrepräsentation Objekte verschiedener Versionen enthalten kann.
Bestimmte Objekte können zusätzlich „Versions-Information", z.B. etwas wie „Firmware-Version" oder eine Versionsnummer, die frei vom Benutzer angegeben wurde, führen. Vom Standpunkt des Export/Import und des XML-Formats aus gesehen wird ein solches Attribut genau wie jedes andere Objektattribut behan- delt (wie z.B. ein Kommentarfeld) und wird in dem „Settings"- Merkmal des Objekts gespeichert.
Das folgende Instanzfragment zeigt Beispiele für alle Arten von Versionsinformationen:
<Document xmlns="http : //www. siemens . com/automation/2004/12/SimaticML"
xmlns :prim="http : //www.profibus . com/Common/2003/ll/Primitives ">
<prim: Documentlnfo Version=" 0.04 ">
<prim:Created Tool="notepad" User="np3304" "/> </prim: Documentlnfo> <ObjectA ID="1" Version="6.1"> <ObjectB ID="2" Name="ObjectBl">
<Settings>
<Propertyl>ll</Propertyl> <Property2>0.5</Property2> <UserVersion>17</UserVersion> </Settings>
</ObjectB> </ObjectA> </Document>
Eine Exportdatei kann möglicherweise nur Teile eines Projekts enthalten. Deshalb ist es möglich, dass sich eine Relation
eines exportierten Objekts auf ein Objekt bezieht, das nicht Teil des Exports ist.
Das folgende Diagramm zeigt ein Beispiel; die Relation zwi- sehen „TH 2" und „Cfc 1" kann sowohl in Export 1 als auch in Export 2 nur als eine „externe Referenz" exportiert werden. Es ist notwendig, dass eine importierende Applikation die Re¬ lation nach dem Import von Exportl und Export2 neu erzeugen kann, wobei die Reihenfolge der teilweisen Importe nicht re- levant sein muss.
Beim Import einer externen Referenz muss die importierende Applikation in der Lage sein, die Referenz korrekt aufzulösen, insbesondere, wenn
o das referenzierte Objekt bereits existiert (z.B. auf¬ grund eines vorherigen Imports) oder
o das referenzierte Objekt über einen nachfolgenden (teil- weisen) Import vollständig erzeugt wird.
Zur Identifikation des Zielobjekts sollten dieselben Mechanismen wie für jedes andere importierte Objekt verfügbar sein. Zu diesem Zweck wird das Zielobjekt als „Hüllobjekt" exportiert, das heißt, es wird als ein „Platzhalter" ohne seinen Inhalt (Einstellungen, untergeordnete Objekte und an¬ dere Beziehungen) in die Exportdatei geschrieben. Ein solches Hüllobjekt führt seine vollständige Namenhierarchie in einem „Path"-Attribut zusätzlich zu dem lokalen Namen (so dass die importierende Applikation Zugang zu der vollen Namenhierarchie hat)
Die „externe" Relation kann nun genau wie eine interne Rela¬ tion in XML geschrieben werden, weil sowohl das Quellen- als auch das Zielobjekt eine Repräsentation in der XML-Datei be¬ sitzen .
<ObjectA ID="1">
<ObjectC Name="ObjectD3" ID="3"> <Relations>
<RelatesTo Target="#4"/> <ObjectB Name=" ObjectBl" ID="4"
Path="ObjectA" Shel- 10bject="true">
<prim:AppId AppName=" SIMATIC" Value="000200lEl0000002"/> <prim:AppId AppName="OtherTool"
Value="0815"/>
</ObjectB> </RelatesTo> </Relations> </ObjectC>
</ObjectA>
Wenn mehrere Instanzen in eine Datei mit derselben externen Instanz in Beziehung stehen, schreibt jede Relation ihr eige- nes Shell-Objekt. Diese Shell-Objekte besitzen ihre eigene eindeutige ID (um sicherzustellen, dass die ID innerhalb ei¬ ner Datei einmalig ist) , beziehen sich aber auf dasselbe Zielobjekt (d.h. zeigen auf denselben Namen, Path und dieselben Appld' s) .
<Device>
<DeviceItem> <Charts>
<CFC Name="Motor" ID="DT000100lAl0000624" Ver- sion="V6.1">
<prim:AppId AppName=" SIMATIC" Value="DT000100lAl0000624" /> <Settings /> <Relations> <PlantHierarchy Target="#12" >
<PlantHierarchyFolder Name="GF34_Befuellen" ID=" 12"
Path="Rubi_AS2_Prj/Rubin/MB3101" Shellθbject="true">
<prim:AppId AppName=" SIMATIC"
Value="OD01101071: 00000029: 00000000: 00000000" />
<prim:AppId AppName="OtherTool" Value="0816" /> </PlantHierarchyFolder>
</PlantHierarchy> </Relations> </CFC>
<CFC Name="Motorl" ID="DT000100lAl0000625" Ver- sion="V6.1">
<prim:AppId AppName=" SIMATIC" Value="DT000100lAl0000625" /> <Settings /> <Relations> <PlantHierarchy Target="#13" >
<PlantHierarchyFolder Name="GF34_Befuellen" ID=" 13"
Path="Rubi_AS2_Prj/Rubin/MB3101" Shellθbject="true">
<prim:AppId AppName=" SIMATIC"
Value="OD01101071: 00000029: 00000000: 0000000 />
<prim:AppId AppName="OtherTool" Value="0816" /> </PlantHierarchyFolder> </PlantHierarchy> </Relations>
</CFC> </Charts> </DeviceItem> </Device>
Zusammengefasst betrifft die Erfindung somit ein Verfahren sowie ein System zur Synchronisation von Daten zwischen Applikationen, bei welchem die Daten zumindest teilweise zwischen den Applikationen ausgetauscht werden, wobei die ausge- tauschten Daten mit in der jeweiligen Applikation vorhandenen Daten synchronisiert werden. Um die Synchronisation zu vereinfachen, wird vorgeschlagen, dass den Daten eine Kennzeichnung für eine Unvollständigkeit zugeordnet wird.
Claims
1. Verfahren zur Synchronisation von Daten zwischen Applikationen, bei welchem die Daten zumindest teilweise zwischen den Applikationen ausgetauscht werden, wobei die ausgetauschten Daten mit in der jeweiligen Applikation vorhandenen Daten synchronisiert werden, wobei den Daten eine Kennzeichnung für eine Unvollständigkeit zugeordnet wird.
2. Verfahren nach Anspruch 1, bei welchem die Daten zumindest teilweise in Form von Hüllobjekten übertragen werden, wobei die Hüllobjekte Attribute zur Identifikation aufweisen, wobei die Hüllobjekte nur Teile eines vollständigen Objekts aufwei¬ sen .
3. Verfahren nach Anspruch 1 oder 2, bei welchem die Daten in einer erweiterbaren Kennzeichnungssprache beschrieben sind.
4. Verfahren nach einem der vorhergehenden Ansprüche, bei welchem beim Import von Daten die Art von Datenänderungen mittels einer Versionskennzeichnung erkannt werden und abhängig von der Versionskennzeichnung eine generische Reaktion erfolgt .
5. Verfahren nach einem der vorhergehenden Ansprüche, bei welchem im Fall bereits synchronisierter Daten bei späteren Synchronisationen nur die Änderungen ausgetauscht werden.
6. Verfahren nach einem der vorhergehenden Ansprüche, bei welchem beim Export von Daten ein Wurzelobjekt ausgewählt wird, ab dem alle Objekte exportiert werden.
7. Verfahren nach einem der vorhergehenden Ansprüche, bei welchem Filtereinstellungen definiert werden und abhängig von den Filtereinstellungen eine Auswahl der auszutauschenden Daten erfolgt .
8. System zur Synchronisation von Daten zwischen Applikationen, wobei Daten zumindest teilweise zwischen den Applikatio¬ nen austauschbar sind, wobei Synchronisationsmittel zur Syn¬ chronisierung der ausgetauschten Daten mit in der jeweiligen Applikation vorhandenen Daten vorgesehen sind, wobei den Daten eine Kennzeichnung für eine Unvollständigkeit zuordenbar ist .
9. System nach Anspruch 8, d a d u r c h g e k e n n z e i c h n e t , dass Hüllobjekte vorgesehen sind, wobei die Daten zumindest teilweise in Form der Hüllobjekte übertragbar sind, wobei die Hüllobjekte Attribute zur Identifikation aufweisen, wobei die Hüllobjekte nur Teile eines vollständigen Objekts aufweisen.
10. System nach Anspruch 8 oder 9, d a d u r c h g e k e n n z e i c h n e t , dass die Daten in einer erweiterbaren Kennzeichnungssprache beschreibbar sind.
11. System nach einem der Ansprüche 8 bis 10, d a d u r c h g e k e n n z e i c h n e t , dass Versionskennzeichnungen zur Kennzeichnung von Datenänderungen vorgesehen sind, wobei die Versionskennzeichnungen zum Auslösen einer generischen Reaktion beim Import der Daten vorgesehen sind.
12. System nach einem der Ansprüche 8 bis 11, d a d u r c h g e k e n n z e i c h n e t , dass Wurzelobjekte vorgesehen sind, welche beim Export von
Daten den Punkt angeben, ab dem alle Objekte exportiert wer¬ den .
13. System nach einem der Ansprüche 8 bis 12, d a d u r c h g e k e n n z e i c h n e t , dass Filtereinstellungen vorgesehen sind und abhängig von den Filtereinstellungen eine Auswahl der auszutauschenden Daten erfolgt .
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 (de) | 2005-04-11 | 2006-04-07 | Synchronisation von daten |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| EP1869548A2 true EP1869548A2 (de) | 2007-12-26 |
Family
ID=36617332
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| EP06725635A Withdrawn EP1869548A2 (de) | 2005-04-11 | 2006-04-07 | Synchronisation von daten |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US8032893B2 (de) |
| EP (1) | EP1869548A2 (de) |
| DE (1) | DE102005016690A1 (de) |
| WO (1) | WO2006108801A2 (de) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| AU2008202631A1 (en) * | 2007-06-14 | 2009-01-08 | Aristocrat Technologies Australia Pty Ltd | 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)
| 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 |
| US8127224B2 (en) | 2003-06-11 | 2012-02-28 | Wtvii, Inc. | System for creating and editing mark up language forms and documents |
| 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 |
-
2005
- 2005-04-11 DE DE102005016690A patent/DE102005016690A1/de not_active Withdrawn
-
2006
- 2006-04-07 US US11/918,307 patent/US8032893B2/en not_active Expired - Fee Related
- 2006-04-07 WO PCT/EP2006/061423 patent/WO2006108801A2/de active Application Filing
- 2006-04-07 EP EP06725635A patent/EP1869548A2/de not_active Withdrawn
Non-Patent Citations (1)
| Title |
|---|
| See references of WO2006108801A2 * |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2006108801A3 (de) | 2007-05-10 |
| US8032893B2 (en) | 2011-10-04 |
| WO2006108801A2 (de) | 2006-10-19 |
| US20090217312A1 (en) | 2009-08-27 |
| DE102005016690A1 (de) | 2006-10-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP1258812B1 (de) | Virtuelle Datenbank heterogener Datenstrukturen | |
| 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 (de) | Rechnergestützte Erzeugung und Änderungsmanagement für Bedienoberflächen | |
| EP1559031A2 (de) | Auf- und abwärtskompatible schemaevolution | |
| DE102012001406A1 (de) | Automatische Konfiguration eines Produktdatenmanagementsystems | |
| EP1869548A2 (de) | Synchronisation von daten | |
| 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 | |
| EP1202166A1 (de) | System zur Verifikation von Software-Anwendungsmodellen in Ketten von Software-Entwurfswerkzeugen | |
| EP1515207A1 (de) | Automatisierungsobjekt und Verfahren zur Beschreibung eines Automatisierungsobjektes unter Verwendung einer Metasprache | |
| Pietranek | Datenmanagementpatterns in multi-skalaren Simulationsworkflows | |
| EP1285315B1 (de) | Informationsverarbeitungssystem und verfahren zu dessen betrieb | |
| WO2000007116A1 (de) | Verfahren, anordnung und satz mehrerer anordnungen zur behebung mindestens einer inkonsistenz in einer datenbankmenge, die eine datenbank sowie mindestens eine kopiedatenbank der datenbank aufweist | |
| EP2757466B1 (de) | Computerimplementiertes Verfahren zum Generieren von Computerprogrammcode | |
| EP1234231B1 (de) | Verfahren zur erzeugung grafischer benutzerschnittstellen für computerprogramme | |
| DE102010010035A1 (de) | Verfahren zum Erstellen von Objekten einer objektorientierten Datenbank | |
| EP1556789A1 (de) | Verwaltung von mit einer erweiterbaren auszeichnungssprache beschriebenen daten | |
| Finkes | A hierarchical Eclipse-based editor for system dependency graphs | |
| DE10109876B4 (de) | Verfahren und Einrichtung zum Datenmanagement | |
| DE19858163A1 (de) | Verfahren zum Übertragen von Informationen zwischen Datenbeständen Client-Applikationen | |
| EP3770769A1 (de) | Verfahren zur abfrage oder bearbeitung einer vollständigen datei mittels einer query language und vorrichtung zur verwaltung des verfahrens | |
| WO2004042556A2 (de) | Strukturierung, speicherung und verarbeitung von daten gemäss einem generischen objektmodell | |
| DE102006037968B4 (de) | Universelle und erweiterbare Datenverwaltung mit Beobachtungs- und Interprozesskommunikations-Mechanismen | |
| Schöler et al. | SAP IT service & application management |
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 |