The example from the Altova web site (below), demonstrates multiple namespaces and re-use: ‘Address_EY’ is defined by the type ‘ipo:EU_address’ that is contained within a separate namespace. Altova XML Spy provides a great visual editing experience, resolving the complexities posed by inheritance, re-use and namespaces, to present an expandable hierarchy derived from the information in the schema and the included and imported schemas. The key challenge these factors pose tool vendors is visualising the schema structure. Easily finding points in a hierarchy and navigating up and down the hierarchy are crucial.Ī schema can contain or inherit re-usable type and element definitions, which can be extended and restricted in different ways, multiple times within the schema. The structure of an XML schema is hierarchical, not a network or a web of relations. In the above diagrams, there are three namespaces, and there may be some names duplicated across the namespaces. That’s a total of 12 schemas whose content is available to schema A, but is not actually contained in the file ‘A.xsd’ that content must all be made available to the schema designer.Ī schema can include structures from multiple namespaces (or semantic models),using a prefix to qualify tags (names) where necessary. The schema marked ‘A’ is a message schema, and it includes or imports the full content of all the schemas marked with a ‘*’. Each box represents a schema – the schema marked ‘B’ is the same schema, and we can see all of its parent and child schemas here. For example, the following diagram contains two partial views of the schema inheritance hierarchy for the OAGi standard. It’s not uncommon for there to be multiple levels of import / include. There are some key differences between the database and XML design paradigms that pose problems for data modelling tool vendors, not because they’re difficult to deal with, but because the tool vendors need to take a new approach to manage them.Īn XML schema can inherit structures from other XML Schemas via Import and Include statements, and the XML designer needs to be able to visualise these structures as if they were part of the content of schema they’re currently working on. XML Spy would of course be used by XML developers to understand and work with the schema, but wouldn’t be used to design it. An XML Schema is, after all, another form of physical data model. This situation is analogous to using data modelling tools to create and edit database schemas, and then creating and updating actual database instances. If the modelling capabilities they provide are good enough, then we stand a chance of persuading developers and designers to use them for schema design, instead of tools like Altova XML Spy. Many have the ability to generate XML schemas from relational models, and some have the ability to model XML directly. There was a disconnect between the Entity-Relationship and UML tools on the one hand, and XML schemas on the other, with the exception of a few integrated toolsets, such as Mega.ĭata modelling tools have moved on a lot since those days. At the time, there was nothing we could do to help them, unless we wanted to build our own XML generator. If we could generate the XML from our models they would use it, otherwise they’d be forced to handcraft them in their favourite XML editor, using their own naming and definition standards. The structure of a parcel of XML (a “document” or a “message”) must adhere to the rules defined in an agreed set of semantics, or data model.īack in 2004, some of the developers I spoke to accepted the need to base their schemas on existing data models, but weren’t willing to do this manually. In order to use XML to successfully integrate data from disparate sources, we must have semantic consistency between schemas. Without that architecture, all we have is some shiny metal. The “bullet” is whatever mechanism we use to transport the XML silver to its destination – service-oriented architecture (SOA), or whatever architecture the XML fits into. In reality, XML is only a partial solution to data integration issues perhaps it’s just the shiny silver plating on the bullet, not the bullet itself. In 2004 I was repeatedly told by developers that we don’t need data models anymore – extensible markup language (XML) is the “silver bullet” that solves all data integration issues.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |