- From: Roger L. Costello <costello@mitre.org>
- Date: Tue, 01 Feb 2000 09:31:03 -0500
- To: xml-dev@ic.ac.uk, www-xml-schema-comments@w3c.org, "Costello,Roger L." <costello@mitre.org>, "Los,Michael E." <mel@mitre.org>, "Schneider,John C." <jcs@mitre.org>, "Kazura,Amy L." <alk@mitre.org>, "Ripley,Michael W." <rip@mitre.org>, "Heller,Mark J." <heller@mitre.org>
Hi Folks, I have a few thoughts about XML Interoperability that I would like to kick around with ya'll. First, a definition of XML Interoperability: Definition. XML Interoperability: the ability of an application to make effective use of an XML document that it receives. There are two ends of the XML Interoperability spectrum: [1] At one end of the spectrum an application is coded for a specific schema and this is able to make effective use of only XML documents that conform to that schema. [2] At the other end of the spectrum the application is able to make effective use of any XML document that it receives, regardless of the schema that the XML document conforms to. I contend that [2] is the desired goal, but [1] is where we are at currently. So, how do we get to [2]? That's what I wish to explore. Question. If an application receives an XML document that conforms to a schema for which the application has no familiarity, how does the application "make effective use" of it? Answer. From my own life, when I am exposed to a new idea I learn best by relating the new idea to something that I already know. Similarly, if an application receives an XML document that contains new, unfamiliar elements/attributes then it may be able to still make use of them (the unfamiliar elements/attributes) if it can relate them to elements/attributes that it knows about. For example, suppose that the XML Document contains an element <metro>, and <metro> is an element for which the application has not been coded to understand. In other words, <metro> is an unfamiliar element to the application. Now let's suppose that there is some way for the application to discover relationships. Suppose that the application looks into a "relationship database" and discovers that <metro> is exactly equivalent to <train>. Let's further suppose that the element <train> is something that the application is familiar with. The application is now able to "make effective use" of the <metro> element. So, what are the key components of XML Interoperability? There are two components: (1) Describing Relationships: there must be a language for describing the relationships between things. In the above example we saw the need to describing the relationship "the <metro> element is exactly equivalent to the <train> element". This is, of course, a very simple relationship. There are many other types of relationships that we would like to be able to express. (2) Discovering Relationships: the relationships that are described must be physically put somewhere. Typically, these relationships will relate elements/attributes/element groups/attribute groups from two or more XML Schemas. Intuitively, it seems to me that these relationships belong in some kind of "relationship database". If you are familiar with the XLink working draft, the previous description may sound a lot like XLink. I agree. Let's take a look at linking in general and XLink in particular. Link. A link is a means for expressing relationships between two or more items. The items could be a document or an element or an attribute, or anything. XLink. XLink has the notion of putting link expressions into a separate link database document (called a linkbase). Something analogous is needed to support XML Interoperability. I am calling the repository of relationships a "relationship database". However, there are differences between an XLink linkbase and a relationship database. Whereas XLink is intended for linking XML instance documents, the "relationship links" described above is intended for relating (linking) XML Schema definitions. Further, the purpose of the "relationship link" is different from an XLink link. The "relationship link" characterizes the relationship between two items, such as "isA", "equivalence", etc. Contrast that with an XLink link whose purpose is to describe things like "should I traverse the link on activation, should I create a new window, etc". Thus, I see a modified form of XLink playing with XML Schemas to enable XML Interoperability: XLink(modified) + XML Schema = XML Interoperability Some other, random thoughts - discovering a relationship may involve several "hops"; e.g., "A is related to B, and B is related to C. The application knows about C. Therefore, the application has an understanding of A." - we need to characterize the possible relationships - isA, equivalence, what else? - need to consider transitivity, commutativity of relationships. - currently, XML Schemas has some support for expressing relationships, namely we can express that element A is exactly equivalent is element B. This is good. However, I would argue that this expression of equivalence relationships belongs more appropriately in a separate document, in a "relationship database", as described above. Okay, this message is long enough. Any comments? /Roger
Received on Tuesday, 1 February 2000 09:29:23 UTC