EP1556789A1 - Verwaltung von mit einer erweiterbaren auszeichnungssprache beschriebenen daten - Google Patents

Verwaltung von mit einer erweiterbaren auszeichnungssprache beschriebenen daten

Info

Publication number
EP1556789A1
EP1556789A1 EP03773544A EP03773544A EP1556789A1 EP 1556789 A1 EP1556789 A1 EP 1556789A1 EP 03773544 A EP03773544 A EP 03773544A EP 03773544 A EP03773544 A EP 03773544A EP 1556789 A1 EP1556789 A1 EP 1556789A1
Authority
EP
European Patent Office
Prior art keywords
objects
file
data
xml
files
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.)
Ceased
Application number
EP03773544A
Other languages
English (en)
French (fr)
Inventor
Heinrich Kulzer
Rainer Heller
Marcus Bürgel
Edgar Frank
Dieter Wissmann
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
Siemens Corp
Original Assignee
Siemens AG
Siemens Corp
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, Siemens Corp filed Critical Siemens AG
Publication of EP1556789A1 publication Critical patent/EP1556789A1/de
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/289—Object oriented databases
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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

Definitions

  • the invention relates to a method and a system for managing data described with an expandable markup language.
  • Data is often described using an expandable markup language.
  • This text-based format is used both as an exchange format and as a storage format.
  • a disadvantage of the format arises from the fact that the data volume can very quickly become very extensive due to this storage format.
  • Objects are often stored in the data storage (e.g. objects from the world of automation). If these are to be read in again, this can be quite complex. Especially if an application is only interested in a subset of the objects or only part of the data. However, the entire file must always be read and edited sequentially, since data can be stored and processed in a stream-oriented manner using expandable markup languages.
  • the invention has for its object to simplify the management of data described with an expandable markup language.
  • This object is achieved by a method for managing data described with an expandable markup language, the data being structured in the form of objects, parts of the objects being storable in first files, the parts each representing a logical unit of an object and one being second file with first means for referencing the components is provided as a higher-level, object-based logical level for storing the objects.
  • This object is achieved by a system for managing data described with an expandable markup language, objects being provided for structuring the data, parts of the objects being storable in first files, the parts each representing a logical unit of an object and a second A file with first means for referencing the components is provided as a higher-level, object-based logical level for storing the objects.
  • Networks of objects are often stored in a large file or divided into a large number of small files. Connections between objects are either predefined by the storage structure or by links that represent references between the files and objects located therein.
  • the invention proposes a method and a system with which the filing of
  • Parts (hereinafter also called features) of an object can be swapped out to first files.
  • One or more outsourced object parts are stored in the respective first file. In this case, the object remains in the original file. Only one or more features of the object are outsourced. This enables navigability to the object within the source file up to the outsourced object part (feature). In addition, the object parts remain movable without having to change references to them.
  • the outsourced components are themselves objects.
  • the second file also called the original file
  • the swapped object is stored as a whole in the respective first file, also called swap file. An object can thus be moved without having to change references to the object. Furthermore, navigability to the object within the original file or from outside is made possible.
  • the components of the objects called features are advantageously stored in object-specific generic containers, the containers being used for referencing the respective object.
  • the features are stored in a container, also referred to below as a proxy object or object surrogate.
  • This representative object represents a shell for the data of the object in a generic manner and forms the Context for storing the features.
  • the context is the identification of the object as it is identified in the original file.
  • the proxy object is an object type that represents a generic object and can include any features.
  • the data of the object are not alone in the swap file, but have a reference to the actual object in the original file through the proxy object and thus provide a backward reference.
  • FIG. 2 shows a schematic illustration of the swapping of a part of an object into a swap file.
  • XML is used as an example for an extensible drawing language.
  • Data in XML files are read sequentially and parts of the file that are not required are skipped.
  • the XML syntax is very helpful here. It stipulates that data is always provided with a start and end tag with the same name (e.g. ⁇ DisplayName>) or the tag is immediately closed again (e.g. ⁇ Text ... />)
  • the link between objects is represented by a link to the file.
  • the information about the object in the target file is missing in the original file - there is typically only the information that one or more objects are stored there.
  • the storage of this data can be divided into several files.
  • an XML schema for the storage of objects and their components is defined.
  • Another object-based logical level is thus introduced above the level of pure XML. At this level it is possible to distribute objects or parts of objects across several files. It is no longer necessary to store all objects in an overall file. Instead, it is possible to store objects so that the core information required to identify the object and its type is available in an original file. The actual (usually extensive) useful information of the object is, however, transferred to a swap file. Data from one or more objects can be stored in this. Here one makes use of the fact that objects mostly consist of different “types of data *. So you can differentiate them in data,
  • Split components that form logical units and represent certain aspects of an object.
  • Basis of Grouping is the logical connection of the components of the object to a specific "view * (e.g. EMI, hardware, software) of the object. These components are also referred to below as features.
  • a logical object model and a mechanism for the division of object data are defined, which allow object meshes to be stored in hierarchically structured files and thereby distribute the data of objects over several files that meet the different requirements for data access , ie support the most important use cases for the use of the data.
  • features can also be exported to a file.
  • the object remains in the original file. Only one or more features of the object are outsourced.
  • the features are stored in an object surrogate in the swap file.
  • This proxy object represents a shell for the data of the object in a generic manner and forms the context for the storage of the features.
  • the context is the identification of the object as it is identified in the original file.
  • the deputy is an object type that represents a generic object and can include any features.
  • references to outsourced objects contain various data (as XML attributes or possibly also as XML elements):
  • the addressing of the object in the paging file can be changed independently of the identification of the object.
  • Rules regarding the locations at which objects or meshes of objects stored in XML files are to be divided must be defined specifically for the application and implemented in a corresponding XML schema.
  • An example of the application of the invention is the export of data from an application in order to be able to process it further in other applications.
  • objects are structured in trees (with cross references by references to any objects).
  • Objects are only swapped to other files at subtree boundaries. All objects and features at the highest logical level in an outsourced file therefore belong to the same object / feature in the original file.
  • This automatically creates a tree-like hierarchy of files when the XML export is divided into several files.
  • Individual features are stored in separate files. This is e.g. This is advantageous, for example, when an application stores its data in its own features, which are essentially only relevant for this application, but not for others. If these are in a separate file, the application only needs to read this file.
  • Every XML file begins with a standard header to identify that this XML file belongs to a set of export files that contain the stored object network.
  • any export file can be used as an entry for processing. It offers simple navigation at the file level to get to the root element or the direct (logical) parent of the file from any file.
  • a standard header is defined for the structure of an (export) data file (e.g. ⁇ Document>). Two optional attributes Parent and Root can be provided in this header.
  • the Racks.xml 20 file is part of an XML export, the root of which is the HWKonfigExport .xml 10 file.
  • This file 10 is also the parent node of Racks.xml 20 in the tree of the XML export.
  • the parent relationship and the root relationship are shown in FIG. 1 by the arrows designated with the reference numerals 2 and 3, respectively.
  • This reference 13 indicates that it is a swap 23.
  • Reference 13 specifies which object was swapped out and in which file it can be found.
  • the relationship between reference 13 on one side and outsourcing 23 on the other side is shown in FIG. 1 by an arrow with reference number 1.
  • An example of a schema definition of an outsourcing reference might look like this:
  • the attributes TargetlD 11 and TargetName 12 contain the ID 21 and the name 22 of the outsourced object to which reference 13 refers.
  • the ID 21 is required for the creation of absolute references from another location to the object.
  • the object can also be given a name 22, which can also be used for referencing. Even if an object is swapped out, these two attributes TargetName 12 and TargetID 11 give the name 22 or ID 21 to the main document. This has the advantage that all references to this object can be navigated in the file. I.e. If the original file of the object is read in / processed by an application, references to the object can be resolved and the object can be read from the swapped file if required.
  • swap references are very simple, only the embedded object (in the example the "Rack") is replaced by an swap reference (in the example "RackLink”).
  • the element is defined in the product-specific schema as an element of the type product: ReferencePartOfT.
  • Target "Feature. Xml # l ⁇ / f eature (ProfibusFeature)" />
  • This object envelope (ObjectSurrogate) is a generic container for storing outsourced features. It is not specific for the application object type whose data it contains.
  • the object envelope serves to establish the appropriate context for the object part and includes the identification of the object (ID and name). As you can see in the instances, the ID and name in the main file and in the swap file are the same. 2 illustrates this relationship.
  • Reference number 50 denotes the original situation when everything is stored in a file:
  • the subsystem object 51 has the two features DisplayNameFeature 52 and ProfibusFeature 53.
  • Reference number 60 denotes the constellation in which the Profibus feature 63 is in a separate file 65 is outsourced.
  • the definitions of the required types in the XML schema could look as follows:
  • the type of ProfibusFeature is derived from the basic type FeatureT. Since the SubstitutionGroup feature was specified in the element declaration, the element can be attached to the ObjectSurrogate instead of the feature.
  • the handling of outsourcing can be supported by a support library for a concrete implementation. This can automatically handle the division of the XML data into files, both when reading the XML data and when writing, and can hide the mechanism for the user. In his view, he only operates on the object model. Management of files and references is done by the support library. The prerequisite for this is that there are corresponding schemas for the application data and that these are used by the support library.
  • the invention thus relates to a system and a method for the simplified management of data described with an expandable markup language.
  • the data is structured in the form of objects, parts of the objects being storable in first files, the parts each representing a logical unit of an object and a second file with first means for referencing the parts as a higher-level, object-based logical level for storage the objects is provided.

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)

Abstract

Die Erfindung betrifft ein System sowie ein Verfahren zur vereinfachten Verwaltung von mit einer erweiterbaren Auszeichnungssprache beschriebenen Daten. Dabei werden die Daten in Form von Objekten strukturiert, wobei Bestandteile der Objekte in ersten Dateien speicherbar sind, wobei die Bestandteile jeweils eine logische Einheit eines Objekts abbilden und wobei eine zweite Datei mit ersten Mitteln zur Referenzierung der Bestandteile als übergeordnete, objektbasierte logische Ebene zur Speicherung der Objekte vorgesehen ist.

Description

Beschreibung
Verwaltung von mit einer erweiterbaren Auszeichnungssprache beschriebenen Daten
Die Erfindung betrifft ein Verfahren sowie ein System zur Verwaltung von mit einer erweiterbaren Auszeichnungssprache beschriebenen Daten.
Daten werden häufig mit einer erweiterbaren AusZeichnungssprache beschrieben. Eine solche Auszeichnungsspräche ist z. B. XML (= Extensible Markup Language) . Dieses textbasierte Format wird sowohl als Austauschformat als auch als Speicherformat verwendet. Ein Nachteil des Formats ergibt sich dadurch, dass das Datenvolumen durch dieses Ablageformat sehr schnell sehr umfangreich werden kann. In der Datenablage werden oft Objekte abgelegt (z. B. Objekte aus der Automatisierungswelt) . Sollen diese wieder eingelesen werden, so kann dies recht aufwendig sein. Insbesondere wenn sich eine Applikation nur für eine Teilmenge der Objekte bzw. nur einen Teil der Daten interessiert. Es muss dennoch immer die gesamte Datei sequenziell gelesen und bearbeitet werden, da mit erweiterbaren Auszeichnungssprachen Daten in Dateien stream-orientiert abgelegt und verarbeitet werden.
Der Erfindung liegt die Aufgabe zugrunde, die Verwaltung von mit einer erweiterbaren Auszeichnungssprache beschriebenen Daten zu vereinfachen.
Diese Aufgabe wird durch ein Verfahren zur Verwaltung von mit einer erweiterbaren Auszeichnungssprache beschriebenen Daten gelöst, wobei die Daten in Form von Objekten strukturiert werden, wobei Bestandteile der Objekte in ersten Dateien speicherbar sind, wobei die Bestandteile jeweils eine logische Einheit eines Objekts abbilden und wobei eine zweite Datei mit ersten Mitteln zur Referenzierung der Bestandteile als übergeordnete, objektbasierte logische Ebene zur Speicherung der Objekte vorgesehen ist.
Diese Aufgabe wird durch ein System zur Verwaltung von mit einer erweiterbaren Auszeichnungsspräche beschriebenen Daten gelöst, wobei Objekte zur Strukturierung der Daten vorgesehen sind, wobei Bestandteile der Objekte in ersten Dateien speicherbar sind, wobei die Bestandteile jeweils eine logische Einheit eines Objekts abbilden und wobei eine zweite Datei mit ersten Mitteln zur Referenzierung der Bestandteile als übergeordnete, objektbasierte logische Ebene zur Speicherung der Objekte vorgesehen ist.
Objektgeflechte werden oft in einer großen Datei abgelegt oder aber auf eine Vielzahl kleiner Dateien aufgeteilt. Zusammenhänge zwischen Objekten sind entweder durch die Ablagestruktur vorgegeben oder aber durch Links, die Verweise zwischen den Dateien und darin befindliche Objekte repräsentieren, abgebildet. Die Erfindung schlägt ein Verfahren sowie ein System vor, mit dem man die Ablage von
Objekten und Objektgeflechten auf mehrere Dateien aufteilen kann. Der Zugriff auf das Objektgeflecht wird dabei optimiert. Die Anzahl zu lesender Dateien - und damit die Datenmenge, die gelesen werden muss - wird reduziert. Grundlage hierfür ist, dass über der Ebene mit in einer reinen Auszeichnungssprache beschriebenen Daten eine weitere, logische Ebene für Objekte definiert wird. D. h. ein Verfahren bzw. System zur Abbildung von Objekten mit ihren Daten in der Auszeichnungssprache. Applikationen, die die Daten lesen, müssen nicht das gesamte Objektgeflecht und dessen Daten lesen, sondern können die logische Objektebene nutzen um nur bis bis zu der Granularität lesen, die sie für ihre Arbeiten auf dem Objektgeflecht benötigen. Tools, die bestimmte Teile des Objektgeflechts nicht benötigen, können so die entsprechenden Stellen sehr leicht überlesen, da die
Daten bzw. die Informationen in separaten Auslagerungsdateien abgelegt werden. Diese Teile müssen vom Parser der AusZeichnungssprache nicht eingelesen und bearbeitet werden. Es können Teile (im Folgenden auch Features genannt) eines Objekts in erste Dateien ausgelagert werden. In der jeweiligen ersten Datei werden ein oder mehrere ausgelagerte Objektteile abgelegt. In der Ursprungsdatei verbleibt in diesem Fall das Objekt. Nur ein oder mehrere Features des Objekts werden ausgelagert. Dies ermöglicht Navigierbarkeit auf das Objekt innerhalb der Ursprungsdatei bis hin zum ausgelagerten Objektteil (Feature) . Zudem bleiben die Objektteile verschiebbar, ohne dass Referenzen hierauf geändert werden müssen.
Gemäß einer vorteilhaften Ausgestaltung der Erfindung sind die ausgelagerten Bestandteile selbst Objekte. In der zweiten Datei, auch Ursprungsdatei genannt, verbleibt jeweils nur ein Objektrumpf in Form einer Auslagerungsreferenz. Dies stellt sicher, dass Referenzen auf das ausgelagerte Objekt sich nicht von anderen Objektreferenzen, die Objekte oder Objektteile in der Ursprungsdatei referenzieren, unterscheiden. Es muss am Ursprung der Referenz nicht bekannt sein, dass es sich bei dem Zielobjekt um ein ausgelagertes Objekt handelt. In der jeweiligen ersten Datei, auch Auslagerungsdatei genannt, wird das ausgelagerte Objekt als Ganzes abgelegt. Ein Objekt kann somit verschoben werden, ohne dass Referenzen auf das Objekt zu ändern sind. Des Weiteren wird Navigierbarkeit auf das Objekt innerhalb der Ursprungsdatei bzw. von Außen ermöglicht.
Vorteilhafterweise werden die Features genannten Bestandteile der Objekte in objektspezifischen generischen Containern gespeichert, wobei die Container zur Referenzierung des jeweiligen Objekts dienen. In der Auslagerungsdatei werden die Features also in einem Container, im Folgenden auch Stellvertreterobjekt oder Objektsurrogate genannt, abgelegt. Dieses Stellvertreterobjekt repräsentiert in generischer Weise eine Hülle für die Daten des Objekts und bildet den Kontext für die Ablage der Features. Der Kontext ist dabei die Identifikation des Objekts, wie es in der Ursprungsdatei identifiziert wird. Es gibt somit ein Stellvertreterobjekt in der Auslagerungsdatei, das beschreibt zu welchem Objekt in der Ursprungsdatei die Daten gehören. Das Stellvertreterobjekt ist ein Objekttyp, der ein generisches Objekt repräsentiert und beliebige Features aufnehmen kann. In der Auslagerungsdatei stehen die Daten des Objekts nicht alleine, sondern haben durch das Stellvertreterobjekt einen Bezug zum eigentlichen Objekt in der Ursprungsdatei und stellen somit eine Rückwärtsreferenz zur Verfügung.
Nachfolgend wird die Erfindung anhand der in den Figuren dargestellten Ausführungsbeispiele näher beschrieben und erläutert.
Es zeigen:
FIG 1 eine schematische Darstellung der Auslagerung eines Objekts in eine Auslagerungsdatei und
FIG 2 eine schematische Darstellung der Auslagerung eines Teils eines Objekts in eine Auslagerungsdatei.
In den Ausführungsbeispielen wird XML als Beispiel für eine erweiterbare Aus zeichnungsspräche verwendet. Daten in XML- Dateien werden sequenziell gelesen und nicht benötigte Teile der Datei überlesen. Dabei ist die XML-Syntax sehr hilfreich. Sie sieht vor, dass Daten immer mit einem Start- und Ende-Tag gleichen Namens versehen werden (z. B. <DisplayName>) bzw. das Tag sofort wieder geschlossen wird (z. B. <Text .../>)
Beispiel :
<DisplayName>
<Text Value="DP-Master" /> </DisplayNarne> Somit ist es für das einlesende Tool („Parser* genannt) möglich, Daten beginnend bei einem bestimmten Start-Tag bis zum zugehörigen Ende-Tag zu überlesen. Der Inhalt des Files zwischen den Tags muss jedoch dennoch gelesen werden, auch wenn die Daten nicht verarbeitet werden. Eine Methode zum Aufteilen von Datenbeständen auf mehrere File bietet das vom W3C Konsortium vorgeschlagene XML-Inclusions (XInclude) Konstrukt. Dies gehört zu den Basisdefinitionen von XML, die vom W3C (= World Wide Web Consortium) momentan erarbeitet werden. XInclude funktioniert als einfacher Mechanismus, um XML oder Textdateien in ein XML Dokument zu inkludieren. Dies geschieht analog dem aus C/C++ bekannten #include als textuelle Ersetzung des Xinclude-Tags durch das andere Dokument. Es können dabei entweder das gesamte Dokument oder nur Teile daraus (spezifiziert durch einen XPointer, siehe XML-Spezifikation) eingebettet werden. Dies löst jedoch nicht das Problem des Überlesens von nicht benötigten Objektteilen, da XML-Parser automatisch die referenzierten Dateien beim Lesen mit einfügen. Die zu hantierende Datenmenge bleibt dabei gleich. Beim Überlesen von nicht interessierenden Teilen der Datei gilt dasselbe wie oben beschrieben. Das Problem hierbei ist, dass XML an sich nur Daten repräsentiert und kein Objektmodell kennt. Somit können logisch in Objekten zusammenhängende Daten auf XML Ebene nicht erkannt werden. Eine weitere, heute gebräuchliche Möglichkeit ist die Aufteilung großer Datenfiles auf eine Vielzahl kleiner Dateien. Hierbei wird typischerweise so vorgegangen, dass die Grenze zwischen Dateien auch immer die logische Objektgrenze bildet. Damit werden Objekte der Anwendungsebene in einer
Datei abgelegt. Der Bezug zwischen Objekten wird durch einen Link auf die Datei abgebildet. Somit fehlt in der Ursprungsdatei die Information über das Objekt in der Zieldatei - es existiert typischerweise nur die Information, dass dort ein oder mehrere Objekte abgelegt sind. Um die Hantierung von großen XML-Datenmengen, die Objekte mit ihren Daten beinhalten, zu optimieren, kann die Ablage dieser Daten auf mehrere Dateien aufgeteilt werden. Hierfür wird ein XML-Schema zur Ablage von Objekten und ihrer Bestandteile definiert. Oberhalb der Ebene des reinen XML wird somit eine weitere, objektbasierte logische Ebene eingeführt. Auf dieser Ebene ist es möglich, Objekte bzw. Teile von Objekten auf mehrere Dateien zu verteilen. Dabei müssen nicht mehr alle Objekte in einer Gesamtdatei abgelegt werden. Stattdessen ist es möglich, Objekte so abzulegen, dass die Kerninformation, die notwendig ist, um das Objekt und dessen Typ zu identifizieren, in einem Ursprungsfile vorhanden ist. Die eigentliche (meist umfangreiche) Nutzinformation des Objekts wird jedoch in ein Auslagerungsfile ausgelagert. In diesem können Daten von einem oder mehreren Objekten abgelegt sein. Hierbei macht man sich zu Nutze, dass Objekte meist aus verschiedenen „Arten von Daten* bestehen. So kann man diese unterscheiden in Daten,
- die das Objekt an sich beschreiben (Objektidentifikation, Name, etc. ) , die von allgemeinem Interesse sind und damit für verschiedene Applikationen bzw. Teile von Applikationen von Interesse sind und
- die sehr spezifisch sind und nur für eine bestimmte Applikation bzw. eine Teil-Applikation von Interesse sind.
Dies kann man ausnutzen, um ein Objekt in logische Bestandteile aufzuteilen und diese ggf. entsprechend den Hauptverwendungen optimiert in verschiedenen Dateien abzulegen. Tools, die bestimmte Teile des Objektgeflechts nicht benötigen, können so die entsprechenden Stellen sehr leicht überlesen, da die Informationen in separate Auslagerungsfiles abgelegt werden. Diese Teile müssen vom XML-Parser nicht eingelesen und bearbeitet werden. Die Daten eines Objekts werden dementsprechend in verschiedene
Bestandteile aufgeteilt, die logische Einheiten bilden und bestimmte Aspekte eines Objekts repräsentieren. Grundlage der Gruppierung ist die logische Zusammengehörigkeit der Bestandteile des Objekts zu einer bestimmten „Sicht* (z. B. EMI, Hardware, Software) auf das Objekt. Diese Bestandteile werden im Folgenden auch als Features bezeichnet. Sie gruppieren die Parameter, Referenzen, etc. des Objekts. Über der syntaktischen Ebene von reinem XML wird also ein logisches Objektmodell und ein Mechanismus zur Aufteilung von Objektdaten definiert, der es gestattet Objektgeflechte in hierarchisch strukturierte Dateien abzulegen und dabei die Daten von Objekten auf mehrere Dateien zu verteilen, die den unterschiedlichen Anforderungen für den Datenzugriff genügen, d. h. die wichtigsten UseCases für die Nutzung der Daten unterstützen.
Dem liegen folgenden Grundideen zugrunde: - Die in XML abzulegenden Daten werden als Objekte modelliert und können über XML-Schema beschrieben werden. Hierdurch ist es möglich eine Semantik für die Auslagerung von Objekten zu definieren. Dabei ist es sinnvoll, dass alle Objekttypen im XML-Schema von einem Basis-Objekttyp abgeleitet werden. Dies ist jedoch nicht zwingend erforderlich. - Es wird ein Mechanismus festgelegt, wie Objekte bzw. Objektgeflechte auf mehrere Dateien aufgeteilt werden können. - Die Auftrennung zwischen Dateien erfolgt an solchen
Stellen, an denen im Objektmodell eine PartOf-Beziehung herrscht. Die Annahme hierbei ist, dass, wenn ein Objekt aus weiteren Subobjekten besteht, diese Subobjekte typischerweise Kandidaten für die Auslagerung darstellen. Applikationen bzw. Teile von Applikationen greifen häufig auf unterschiedlicher Granularitätsstufe auf Objekte zu. So interessiert in der einen Applikation beispielsweise nur um welches Objekt es sich handelt. Erst zur Bearbeitung des Objekts (z. B. in einem Editor) sind die Subobjekte dieses Objekts von Interesse. Erst dann wird auf diese Teildaten zugegriffen. - In der Ursprungsdatei verbleibt ein Objektrumpf in Form einer Auslagerungsreferenz. Dies stellt sicher, dass Referenzen auf das ausgelagerte Objekt sich nicht von anderen Objektreferenzen unterscheiden. Es muss am Ursprung der Referenz nicht bekannt sein, dass es sich bei dem Zielobjekt um ein ausgelagertes Objekt handelt. In der Auslagerungsdatei wird das ausgelagerte Objekt als Ganzes abgelegt. Das hat folgende Vorteile:
- Referenzen auf ausgelagerte Objekte müssen sich nicht unterscheiden von Referenzen auf nicht ausgelagerte
Objekte.
- Objekt kann verschoben werden, ohne dass Referenzen auf das Objekt zu ändern sind.
- Navigierbarkeit auf das Objekt innerhalb der Ursprungsdatei bzw. von Außen ist gegeben
- Es können auch Teile eines Objekts (Features) in eine Datei ausgelagert werden. In der Ursprungsdatei verbleibt in diesem Fall das Objekt. Nur ein oder mehrere Features des Objekts werden ausgelagert. In der Auslagerungsdatei werden die Features in einem Objektsurrogate abgelegt.
Dieses Stellvertreterobjekt repräsentiert in generischer Weise eine Hülle für die Daten des Objekts und bildet den Kontext für die Ablage der Features . Der Kontext ist dabei die Identifikation des Objekts, wie es in der Ursprungsdatei identifiziert wird. Das hat folgende Vorteile:
- Es gibt einen Stellvertreter in der Auslagerungsdatei, der beschreibt zu welchem Objekt die Daten gehören.
- Der Stellvertreter ist Objekttyp, der ein generisch.es Objekt repräsentiert und beliebige Features aufnehmen kann.
- Navigierbarkeit auf das Objekt innerhalb der Ursprungsdatei bis hin zum ausgelagerten Objektteil
(Feature) ist gegeben. - Verschiebbarkeit des Objektteils ohne Referenzen hierauf ändern zu müssen (Objekt enthält RumpfInformationen über ausgelagertes Objektteil) . In der Auslagerungsdatei stehen die Daten des Objekts nicht alleine, sondern haben durch das Stellvertreter- Objekt einen Bezug zum eigentlichen Objekt in der Ursprungsdatei (Eine Art Rückwärtsreferenz)
Die Referenzen auf ausgelagerte Objekte beinhalten verschiedene Daten (als XML-Attribute oder ggf. auch als XML- Elemente) :
- Identifikationsdaten des Objekts (z. B. Objekt-ID, Objekt- Name, etc.)
- Zieldatei in der das Objekt zu finden ist (z. B. Name und Pfad der Datei)
- Identifikationsdaten des Objekts in der Zieldatei (z. B. Objekt-ID, Objekt-Name)
Durch diesen Aufbau der Referenz kann die Adressierung des Objekts in der Auslagerungsdatei unabhängig von der Identifikation des Objekts geändert werden. Regeln, an welchen Stellen in XML-Dateien abgelegte Objekte bzw. Objektgeflechte aufzuteilen sind, sind spezifisch für den Anwendungsfall zu definieren und in ein entsprechendes XML- Schema umzusetzen.
Ein Beispiel für die Anwendung der Erfindung ist der Export von Daten aus einer Applikation, um diese in anderen Applikationen weiterverarbeiten zu können. In einer Applikation werden Objekte in Bäumen strukturiert (mit Querverweisen durch Referenzen auf beliebige Objekte) . Eine Auslagerung von Objekten in andere Dateien erfolgt nur an Teilbaumgrenzen. Alle Objekte und Features auf oberster logischer Ebene in einer ausgelagerten Datei gehören deshalb zum gleichen Objekt/Feature in der ursprünglichen Datei. Dadurch entsteht bei der Aufteilung des XML-Exports in mehrere Dateien automatisch eine baumartige Hierarchie von Dateien. Es gibt mehrere Möglichkeiten, wie man ein (logisch zusammengehörendes) Objektgeflecht auf mehrere Dateien verteilen kann: - Aufteilung objektgranular : SubObjekte, die zu einem Objekt gehören werden nicht in der ursprünglichen Datei eingebettet, sondern in eine externe Datei geschrieben.
- Aufteilung an Feature-Grenzen: Einzelne Features werden in getrennten Dateien abgelegt. Dies ist z. B. dann vorteilhaft, wenn eine Anwendung ihre Daten in eigene Features ablegt, die im Wesentlichen nur für diese Applikation relevant sind, nicht aber für andere. Falls diese in einer eigenen Datei liegen, braucht die Anwendung nur diese Datei zu lesen.
Eine Datei, die ausgelagerte Objekte enthält, unterscheidet sich in ihrem Aufbau nicht von anderen Dateien, in denen Objekte abgelegt werden. Jede XML-Datei beginnt mit einem Standard-Header zur Identifikation, dass diese XML-Datei zu einer Menge von Export-Dateien gehört, die das abgelegte Objektgeflecht beinhalten.
Zusätzliche Vorteile bietet es, die hierarchischen Abhängigkeiten zwischen den Dateien in einem Export eines
Objektgeflechts explizit mit anzugeben. Dies ist jedoch nicht notwendig und bietet nur zusätzlichen Nutzen dadurch, dass eine beliebige Datei des Exports als Einstieg für die Bearbeitung verwendet werden kann. Es bietet eine einfache Navigation auf Dateiebene, um von jeder beliebigen Datei aus zum Wurzelelement bzw. zum direkten (logischen) Parent (= Elternelement) der Datei zu gelangen. Hierzu wird für den Aufbau einer (Export-) Datendatei (z. B. <Document>) ein Standard-Header definiert. In diesem Header können zwei optionale Attribute Parent und Root vorgesehen werden. Mit
Parent gibt man die nächsthöhere Datei der Hierarchie an, mit Root direkt die Wurzel, also das oberste Element der Hierarchie. Wenn man diese beiden Attribute verwendet, ist es möglich, von einer beliebigen Datei innerhalb eines Exports zur Wurzel des Exports bzw. zu dem File zu gelangen, von dem die Objektdaten der aktuellen Datei referenziert werden. Der Aufbau des Headers und der gesamten XML Datei kann dabei über XML-Schema festgelegt werden. Ein Beispiel für eine Instanz einer Exportdatei kann wie folgt aussehen (siehe auch FIG 1) .
Beispiel-Datei Racks.xml 20:
<Document xmlns : base="http : //www. siemens . com/lndustry/2001/Automation/Base"
Parent="HWKonfigExport . xml" Root="HWKonfigExport . xml">
<FileInfo Version="1. 2 ">
</FileInfo> </DocuιrιerLt>
Die Datei Racks.xml 20 ist Teil eines XML-Exports, dessen Wurzel die Datei HWKonfigExport .xml 10 bildet. Diese Datei 10 ist gleichzeitig der Vaterknoten von Racks.xml 20 im Baum des XML-Exports. Die Parent-Beziehung und die Root-Beziehung sind in FIG 1 durch die mit den Bezugszeichen 2 bzw. 3 bezeichneten Pfeile dargestellt.
Lagert man ein Objekt mit seinen Daten in eine eigene Datei aus, so benötigt man an der Stelle, wo "normalerweise" das Objekt eingebettet wäre, eine spezielle Referenz 13
(ReferencePartOfT) . Diese Referenz 13 gibt an, dass es sich um eine Auslagerung 23 handelt. Die Referenz 13 spezifiziert dabei welches Objekt ausgelagert wurde und in welcher Datei es zu finden ist. Die Beziehung zwischen Referenz 13 auf der einen Seite und Auslagerung 23 auf der anderen Seite ist in FIG 1 durch einen Pfeil mit dem Bezugszeichen 1 dargestellt. Ein Beispiel für eine Schema-Definition einer Auslagerungsreferenz könnte wie folgt aussehen:
<xsd: complexType name="ReferencePartθfT"> <xsd : complexContent> <xsd:attribute name="Name" type="xsd: string" use=" optional "/>
<xsd : attribute name="Target" type="xsd: string" use="required"/>
<xsd: attribute name="TargetID" type="IdT" use="required"/>
<xsd: attribute name="TargetName" type="xsd: string" use="required"/> </xsd: coraplexContent>
</xsd: complexType>
Die Attribute TargetlD 11 und TargetName 12 enthalten die ID 21 und den Namen 22 des ausgelagerten Objekts, auf das die Referenz 13 verweist. Die ID 21 wird für die Bildung von absoluten Referenzen von einer anderen Stelle auf das Objekt benötigt. Dem Objekt kann auch ein Name 22 gegeben werden, den man ebenfalls zur Referenzierung verwenden kann. Auch wenn ein Objekt ausgelagert wird, sind durch diese beiden Attribute TargetName 12 und TargetlD 11 der Name 22 bzw. die ID 21 noch im Hauptdokument vorhanden. Dies hat den Vorteil, das alle Referenzierungen auf dieses Objekt in dem File navigiert werden können. D. h. wenn das Ursprungsfile des Objekts von einer Applikation eingelesen/verarbeitet wird, so können Referenzen auf das Objekt aufgelöst und das Objekt bei Bedarf aus der ausgelagerten Datei gelesen werden.
Der Einsatz von Auslagerungsreferenzen ist sehr einfach, es wird nur das eingebettete Objekt (im Beispiel das "Rack") durch eine Auslagerungsreferenz (im Beispiel "RackLink") ersetzt. Das Element wird im produktspezifischen Schema als Element vom Typ product :ReferencePartOfT definiert.
Beispiel für den Einsatz der Auslagerungsreferenz: <base: Station ID="1234" Name="S7300"> <base : StructuralFeature>
<base: RackLink TargetName="UR" TargetID="4711"
Target=".. /Drehen/Racks .xml#4711"/> </base:StructuralFeature> </base: Station> Die Definition der Auslagerung des Objekts (Rack) kann im XML-Schema für das Ursprungsobjekt in diesem Fall wie folgt definiert werden:
<xsd: element name="RackLink" type="ReferencePartOfT" />
Die Auslagerung von einzelnen Features eines Objekts führt dazu, dass in der Auslagerungsdatei eigentlich kein vollständiges Objekt mehr vorhanden ist, sondern nur ein Teil des Objekts. An der Stelle im Ursprungsdokument, an der sonst das Feature abgelegt würde, steht nur noch ein Link auf das ausgelagerte Feature. Beispiel:
<SubSystem ID="100" Name="DP- aster"> <DisplayNameFeature>
<DisplayNameFeature>
<ProfibusFeature ink
Target="Feature. xml#lθθ/f eature (ProfibusFeature) " />
</SubSystem>
In der Auslagerungsdatei steht das eigentliche Feature. Damit dieses Feature wieder einem Objekt zugeordnet werden kann, wird dieses Feature in einer Standard-Objekthülle (auch ObjectSurrogate genannt) abgelegt. Beispiel für das in obigem Beispiel ausgelagerte ProfibusFeature:
<ObjectSurrogate ID="100" Name="DP-Master"> <ProfibusFeature>
<GROUP_IDENT_SUM_ALL_SLAVES Value="255"/> <GROUP_SYNC_PROP Value="255"/>
<GROUP_FREEZE_PROP Value="255"/> <LAST_USED_PROFIBUS_ADDR Value="12"/> <Address Value="12"/> </ProfibusFeature> </0b ectSurrogate> Diese Objekthülle (ObjectSurrogate) ist ein generischer Container zur Aufnahme von ausgelagerten Features. Er ist nicht spezifisch für den Applikations-Objekttyp, dessen Daten er enthält. Die Objekthülle dient zur Etablierung des entsprechenden Kontexts für den Objektteil und beinhaltet die Identifikation des Objekts (ID und Name) . Wie man in den Instanzen sieht, sind ID und Name in der Haupt-Datei und in der Auslagerungsdatei jeweils gleich. FIG 2 verdeutlicht diesen Zusammenhang. Mit dem Bezugszeichen 50 wird die ursprüngliche Situation gekennzeichnet, wenn alles in einer Datei abgelegt wird: Das Objekt Subsystem 51 hat die beiden Features DisplayNameFeature 52 und ProfibusFeature 53. Mit dem Bezugszeichen 60 wird die Konstellation bezeichnet, bei der das ProfibusFeature 63 in eine eigene Datei 65 ausgelagert ist. Die Definitionen der benötigten Typen im XML-Schema könnte beispielhaft folgendermaßen aussehen:
<xsd:complexType name="θbj ectSurrogateT "> <xsd: annotation> <xsd:documentation>object that contains features in partial exports</xsd: documentation> </xsd: annotation> <xsd:complexContent>
<xsd: restriction base="θbj ectT"> <xsd:sequence>
<xsd:ele ent name="App_Id" type="ApplicationSpecificIdT" minθccurs="0"
<xsd:element ref="Feature" maxθccurs="unbounded"/> </xsd: seguence>
</xsd: restriction> </xsd: complexContent> </xsd: co plexType>
<xsd:elerent name="Feature" type="FeatureT"/> <xsd:element name="ProfibusFeature" type="ProfibusFeatureT" substitutionGroup="Feature">
<xsd: attribute name="Name" type="xsd:QName" use="optional"/> <xsd: attribute name="Target" type="xsd: string" use="reguired"/> <xsd: attribute na e="Type" type="Ref erenceTypeEnumT" use=" optional" fixed="Partθf"/> </xsd: co plexType>
Der Typ von ProfibusFeature ist vom Grundtyp FeatureT abgeleitet. Da bei der Elementdeklaration die SubstitutionGroup Feature angegeben wurde, kann das Element in das ObjectSurrogate an Stelle von Feature eingehängt werden.
Die Hantierung von Auslagerungen kann bei einer konkreten Implementierung durch eine Supportbibliothek unterstützt werden. Diese kann sowohl beim Lesen der XML-Daten, als auch beim Schreiben automatisch die Aufteilung der XML-Daten auf Files hantieren und den Mechanismus für den Anwender verbergen. Aus seiner Sicht operiert er ausschließlich auf dem Objektmodell. Verwaltung von Dateien und Referenzen erfolgt durch die Supportbibliothek. Voraussetzung hierfür ist, dass entsprechende Schemas für die Applikationsdaten existieren und diese von der Supportbibliothek benutzt werden.
Zusammenfassend betrifft die Erfindung somit ein System sowie ein Verfahren zur vereinfachten Verwaltung von mit einer erweiterbaren Auszeichnungssprache beschriebenen Daten. Dabei werden die Daten in Form von Objekten strukturiert, wobei Bestandteile der Objekte in ersten Dateien speicherbar sind, wobei die Bestandteile jeweils eine logische Einheit eines Objekts abbilden und wobei eine zweite Datei mit ersten Mitteln zur Referenzierung der Bestandteile als übergeordnete, objektbasierte logische Ebene zur Speicherung der Objekte vorgesehen ist.

Claims

Patentansprüche
1. Verfahren zur Verwaltung von mit einer erweiterbaren Auszeichnungssprache beschriebenen Daten, wobei die Daten in Form von Objekten strukturiert werden, wobei Bestandteile der Objekte in ersten Dateien speicherbar sind, wobei die Bestandteile jeweils eine logische Einheit eines Objekts abbilden und wobei eine zweite Datei mit ersten Mitteln zur Referenzierung der Bestandteile als übergeordnete, objektbasierte logische Ebene zur Speicherung der Objekte vorgesehen ist.
2. Verfahren nach Anspruch 1, d a d u r c h g e k e n n z e i c h n e t , dass die Bestandteile selbst Objekte sind.
3. Verfahren nach Anspruch 1, d a d u r c h g e k e n n z e i c h n e t , dass die Bestandteile in objektspezifischen generischen Containern gespeichert werden, wobei die Container zur
Referenzierung des jeweiligen Objekts dienen.
4. System zur Verwaltung von mit einer erweiterbaren Auszeichnungssprache beschriebenen Daten, wobei Objekte zur Strukturierung der Daten vorgesehen sind, wobei Bestandteile der Objekte in ersten Dateien speicherbar sind, wobei die Bestandteile jeweils eine logische Einheit eines Objekts abbilden und wobei eine zweite Datei mit ersten Mitteln zur Referenzierung der Bestandteile als übergeordnete, objektbasierte logische Ebene zur Speicherung der Objekte vorgesehen ist.
5. System nach Anspruch 4, d a d u r c h g e k e n n z e i c h n e t , dass die Bestandteile selbst Objekte sind.
6. System nach Anspruch 4, d a d u r c h g e k e n n z e i c h n e t , dass objektspezifische generische Container zur Speicherung der Bestandteile der Objekte vorgesehen sind, wobei die Container zur Referenzierung des jeweiligen Objekts dienen.
EP03773544A 2002-10-30 2003-10-17 Verwaltung von mit einer erweiterbaren auszeichnungssprache beschriebenen daten Ceased EP1556789A1 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE10250639 2002-10-30
DE10250639A DE10250639A1 (de) 2002-10-30 2002-10-30 Verwaltung von mit einer erweiterbaren Auszeichnungssprache beschriebenen Daten
PCT/DE2003/003451 WO2004040469A1 (de) 2002-10-30 2003-10-17 Verwaltung von mit einer erweiterbaren auszeichnungssprache beschriebenen daten

Publications (1)

Publication Number Publication Date
EP1556789A1 true EP1556789A1 (de) 2005-07-27

Family

ID=32103186

Family Applications (1)

Application Number Title Priority Date Filing Date
EP03773544A Ceased EP1556789A1 (de) 2002-10-30 2003-10-17 Verwaltung von mit einer erweiterbaren auszeichnungssprache beschriebenen daten

Country Status (4)

Country Link
US (1) US20060059167A1 (de)
EP (1) EP1556789A1 (de)
DE (1) DE10250639A1 (de)
WO (1) WO2004040469A1 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080005132A1 (en) * 2006-06-30 2008-01-03 Herbeck David G Method and system for describing and storing bursting metadata in a content management system
US8176167B2 (en) 2006-12-05 2012-05-08 Qualcomm Incorporated Methods and apparaus for requesting wireless communication device performance data and providing the data in optimal file size
US8495176B2 (en) * 2010-08-18 2013-07-23 International Business Machines Corporation Tiered XML services in a content management system
US8762934B2 (en) * 2010-10-15 2014-06-24 Serghei Sarafudinov Method of extensible business object modeling and generation of system artifacts from the models

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6850893B2 (en) * 2000-01-14 2005-02-01 Saba Software, Inc. Method and apparatus for an improved security system mechanism in a business applications management system platform
US6591272B1 (en) * 1999-02-25 2003-07-08 Tricoron Networks, Inc. Method and apparatus to make and transmit objects from a database on a server computer to a client computer
US6920608B1 (en) * 1999-05-21 2005-07-19 E Numerate Solutions, Inc. Chart view for reusable data markup language
US6721747B2 (en) * 2000-01-14 2004-04-13 Saba Software, Inc. Method and apparatus for an information server
WO2001052054A2 (en) * 2000-01-14 2001-07-19 Saba Software, Inc. Method and apparatus for a business applications server
CA2400442A1 (en) * 2000-02-25 2001-08-30 Yet Mui Method for enterprise workforce planning
WO2002046916A2 (en) * 2000-10-20 2002-06-13 Polexis, Inc. Extensible information system (xis)
CA2333243A1 (en) * 2001-01-19 2002-07-19 Ibm Canada Limited-Ibm Canada Limitee A method for providing performance data of a web server
US7216160B2 (en) * 2001-10-31 2007-05-08 Sun Microsystems, Inc. Server-based application monitoring through collection of application component and environmental statistics
US7761337B2 (en) * 2001-12-18 2010-07-20 Siebel Systems, Inc. Data structure for a complex order processing system
US7016919B2 (en) * 2002-03-29 2006-03-21 Agilent Technologies, Inc. Enterprise framework and applications supporting meta-data and data traceability requirements
US20030208493A1 (en) * 2002-04-12 2003-11-06 Hall Bradley S. Object relational database management system
US7051284B2 (en) * 2002-05-16 2006-05-23 Microsoft Corporation Displaying information to indicate both the importance and the urgency of the information
US6986121B1 (en) * 2002-06-28 2006-01-10 Microsoft Corporation Managing code when communicating using heirarchically-structured data

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
LEASE K: "External entities and alternatives", ONLINE PUBLICATION OF PROCEEDINGS OF XML EUROPE CONFERENCE, - 16 June 2000 (2000-06-16), Paris , France, Retrieved from the Internet <URL:http://www.gca.org/papers/xmleurope2000/pdf/s14-02.pdf> [retrieved on 20080214] *

Also Published As

Publication number Publication date
WO2004040469A1 (de) 2004-05-13
US20060059167A1 (en) 2006-03-16
DE10250639A1 (de) 2004-05-13

Similar Documents

Publication Publication Date Title
DE3751228T2 (de) Verfahren und Vorrichtung zur Wiederauffindung von gespeicherten Grafikdaten.
EP1597675A1 (de) System und verfahren zum verwalten und zum austausch von daten eines technischen projektes, einer technischen anlage sowie einzelner anlagenkomponenten
EP1276056B1 (de) Verfahren zum Verwalten einer Datenbank
DE19645128C2 (de) Verfahren zum Verwalten von Dokumenten sowie Gerätetreiber zur Durchführung des Verfahrens
WO2004040441A2 (de) Auf- und abwärtskompatible schemaevolution
WO2004040469A1 (de) Verwaltung von mit einer erweiterbaren auszeichnungssprache beschriebenen daten
EP2601594A1 (de) Verfahren und vorrichtung zur automatischen verarbeitung von daten in einem zellen-format
EP3411803B1 (de) Gerät und verfahren zur bearbeitung eines binärkodierten strukturdokuments
DE102015115797B4 (de) Verfahren zum Erzeugen von elektronischen Dokumenten
EP1515207A1 (de) Automatisierungsobjekt und Verfahren zur Beschreibung eines Automatisierungsobjektes unter Verwendung einer Metasprache
DE10343328A1 (de) Verfahren zum Abbilden eines hierarchischen technischen Systems in eine relationale Datenbank
DE19811524A1 (de) Datenverarbeitungssystem
DE102015117668B4 (de) Verfahren zur Ablage von Daten und zur Abfrage derselben
DE10250642A1 (de) Erweiterung von Datensätzen
DE2613703C2 (de) Schaltungsanordnung zum Übersetzen von Programmtexten
DE10250643A1 (de) Verarbeitung von Daten in generischer und spezifischer Darstellungsform
DE10047338A1 (de) Verfahren zur Datenkompression von strukturierten Dokumenten und Anordnung zur Durchführung des Verfahrens
DE10250638A1 (de) Strukturierung, Speicherung und Verarbeitung von Daten gemäß einem generischen Objektmodell
EP1161723B1 (de) Verfahren zur grafischen darstellung und/oder bearbeitung von werten von datentypen
DE10109876B4 (de) Verfahren und Einrichtung zum Datenmanagement
DE102005016690A1 (de) Synchronisation von Daten
DE102007061939B4 (de) Verfahren zur Bereitstellung eines hierarchisch strukturierten Datensatzes für den Zugriff einer Applikation
EP1239377A1 (de) Datenorganisationssystem und Verfahren zur Gliederungsstrukturverwaltung und -synchronisation
EP1600854A2 (de) Verfahren zum Arbeiten mit Kontaktplan und Funktionsplan und hierzu geeigneter grafischer Editor
DE102004052913A1 (de) Verbesserter Zugriff auf XML-Files mittels eines Positions-Stacks

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

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT RO SE SI SK TR

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 HAS BEEN REFUSED

18R Application refused

Effective date: 20100105