A White Paper for the OASIS XDI Technical Committee
v2, April 12, 2004
Drummond Reed, Cordance
Geoffrey Strongin, AMD
XDI (XRI Data Interchange) is a new service for generalized distributed data sharing and mediation using XRIs (Extensible Resource Identifiers), a URI-compatible abstract identifier scheme developed by the OASIS XRI Technical Committee. The goal of XDI is to enable data from any data source to be identified, exchanged, linked, and synchronized into a machine-readable dataweb using XML documents just as content from any content source can linked into the human-readable Web using HTML documents today. Because the controls needed to mediate access and usage of shared data can be built right into every XDI link, the emergence of a global Dataweb has the potential to do for trusted data interchange what the Web did for open content exchange.
This white paper presents several examples of classic cross-domain data sharing problems, explains how the Dataweb model can provide a generalized solution, and describes the key objectives of the newly formed OASIS XDI Technical Committee http://www.oasis-open.org/committees/xdi.
The Web has dramatically simplified information access. Never in history has content been so readily available or richly linked. Furthermore, this model for distributed systems has become so compelling that the next wave has already broken: Web services—the promise of distributed applications talking to each other in XML and SOAP as easily as Web browsers and servers talk in HTML and HTTP. Yet with cross-domain applications comes another complex problem: the need to share instances of the same data across multiple domains, directories, databases, and applications. There are many facets to this challenge: identification, authentication, authorization, mediation, and synchronization; all problems that were minimized on the Web because it dealt primarily with presentation of data rather than interchange of data. Recently a new approach to this set of needs has emerged called the Dataweb. The Dataweb combines the key principles of Web architecture with core concepts from Web services and the Semantic Web into a solution that can be “the simplicity on the other side of complexity” for distributed data sharing. This white paper presents several common distributed data sharing challenges and then explains how the Dataweb model can be applied to solve them. It then provides more details about how the Dataweb model builds on principles of Web, Web Services, and Semantic Web architectures. It closes by summarizing the mission of the OASIS XDI Technical Committee."I would not give a fig for the simplicity this side of complexity, but I would give my life for the simplicity on the other side of complexity."
-- Oliver Wendell Holmes, Jr.
(^1) http://www.imc.org/pdi/
(^2) http://www.oasis-open.org/committees/ciq/
(^3) http://www.imc.org/pdi/
(^4) http://www.slipstick.com/outlook/share.htm
(^5) http://www.parlay.org/about/pam/index.asp
(^6) http://www.impactalliance.org/
(^7) http://www.nain.org/info/directory.htm
(^8) http://lists.oasis-open.org/archives/legalxml-courtfiling/200
Web and Dataweb architectures are so similar that the primary difference lies in one feature: while Web links can only be one-way "strings" between HTML resource representations, Dataweb links can also be two-way active "pipes" between XML resource representations. This is illustrated graphically in Figure 1:
Figure 1: Web “strings” vs. Dataweb “pipes”.
How exactly is a Dataweb pipe different from a Web string?
(^9) Note that XDI link contracts are not required on every Dataweb link—they are only needed when it is necessary to control the flow or caching of shared data.
This last feature of Dataweb links is critical to building Dataweb trust relationships. On the Web, links are "one-dimensional", i.e., they use the HTML "A" (anchor) tag to specify a single URI for a target resource. On the Dataweb, links can be full three-dimensional resources, i.e., active XDI documents that reference other XDI documents just like a real-world contract might reference items of real property.
This three-dimensional approach to Dataweb links can provide:
What types of controls can XDI link contracts define? Any policy necessary to mediate a data interchange relationship. They are as flexible and extensible as real world contracts (e.g., non-disclosure agreements).
For example, link contracts can mediate:
Furthermore, since link contracts are themselves XDI documents, they can (like real-world contracts) govern their own revision, amendment, and deletion.
In sum, Dataweb link contracts permit fully distributed peer-to-peer data mediation the same way Web links permits fully distributed peer-to-peer content access. They are a solution that models (and scales to) the real world of data sharing.
After link contracts, the second most important contrast between the Web and the Dataweb is addressing.
Both architectures have the same fundamental premise: 100% addressability of every resource. However on the Dataweb this applies to every single item of data, down to the smallest individual attribute.
This is an example of how the addressing requirements for Internet-scale data sharing are more stringent than for content sharing. These requirements are covered in detail in XRI Requirements and Glossary 1.0,^10 published by the OASIS XRI TC.^11 A brief summary is provided in Table 1:
| Requirement | Web (HTTP URIs) | Dataweb Addressing (XRIs) |
|---|---|---|
| Persistence | No standard solution for addresses that do not break when a resource moves or changes names (the Web equivalent of a database global foreign key). | Must support both persistent and reassignable identifiers at any level. |
| Unlimited delegation & federation | Supports delegation only in DNS names (e.g., the first segment of an HTTP URI —"www.example.com"). | Must support delegation of both persistent and non-persistent identifiers to any depth. |
| Global contexts | DNS top-level domains provide limited global context for an identifier. (Exceptions are restricted TLDs like ".name" for individuals and “.pro” for professionals.) | Must support four global contexts ^ personal, organizational, general, and special. |
| Cross-references | URIs cannot be nested in other URIs to permit sharing of identifiers across domains. | Must allow XRIs (and URIs) to be nested within XRIs to any depth. |
| Self-references | No syntax for referring to "the concept represented by an identifier" rather than an actual resource to which the identifier resolves. | Must provide standard syntax for self-references. |
| Internationalization | Partially internationalized. IRIs (Internationalized Resource Identifiers) in progress. | Must be fully IRI compliant. |
| Extensibility | Extensible through new URI schemes and resolution protocols. | Must be extensible within the XRI scheme and resolution protocol. |
Table 1: The requirements for Dataweb addressing.
In addition to the new capabilities of XRI syntax, XDI also supports XRI synonyms. An XRI synonym is established whenever two or more XRIs—regardless of their syntactic equivalence—are asserted in an XDI document to represent the same resource. XRI synonyms are the way XDI can maintain both human-friendly reassignable XRIs (e-names) and machine-friendly persistent XRIs (e-numbers) for the same resource at any scope—global, local, or relative. So a resource can have both multiple e-names (e.g., in different languages) and multiple e-numbers (e.g., for different data sharing and privacy contexts)—all managed automatically by how the XRIs are assigned and shared using XDI link contracts.
In short, XRI addressing is how XDI can solve one of the most challenging problems in enterprise application integration (EAI): mapping and translating data between domains. With XDI you can finally, "Map once, link everywhere".
(^10) http://xml.coverpages.org/XRI-RequirementsV10-2003
(^11) http://www.oasis-open.org/committees/xri/
HTML was a breakthrough in network hypertext because it provided a simple, application-, domain-, and language-independent format for content representation. Without it, the Web could never have achieved ubiquity. To emulate this vital feature, the Dataweb must do the same for data representation in XML.
On the surface this would appear to be an immense challenge due to the enormous variety of existing XML schemas and schema languages. However the purpose of the XDI meta-schema is quite the opposite: to provide a simple, universal, “schema-neutral” format for exchanging, linking, and synchronizing other XML-encoded data (or references to other URI-addressable data). In essence, XDI is an XML "wrapper" or “descriptor” for instances of XML defined in any schema language.
Thus the proposed XDI meta-schema (see Appendix A) has only four XML elements (and no XML attributes) as shown in the UML relationship diagram in Figure 2:
Figure 2: UML model of the XDI meta-schema.
Like HTML, the purpose of the XDI schema is to reach "the simplicity on the other side of complexity" for distributed data sharing. Despite its simple structure, the expressive power of XRIs allows instances of the XDI meta-schema to identify, exchange, link, and synchronize any XML-encoded or URI-referenceable data between any two locations or applications on the Internet.
Of all the components of Dataweb architecture, the one that most resembles its Web ancestry is the proposed XDI service definition. Although defined abstractly using WSDL, it is proposed to consist of the same four basic operations as HTTP:^12
The advantage of defining XDI service abstractly in WSDL is that it can be bound to any transport protocol. So even though XDI can be used "natively" over HTTP, it is equally at home using the full XML enveloping and messaging capabilities of SOAP. XDI can also be bound to SMTP/MIME as a simple way to extend structured data interchange to Internet email.
Having described the Dataweb model, now let’s illustrate how it can be applied to our three distributed data sharing problems.
The first challenge is to share and link electronic business cards between dynamic address books—and do so in a way that is interoperable across domains like Internet email and the Web. As explained above, the Dataweb approach to this problem is just like the Web. Specifically, once Web servers and browsers were available, all an author had to do to begin sharing information over the Web was:
To begin sharing and linking data such as a business card over the Dataweb, the process is nearly identical, with the addition of one more step:
Note these last two steps: on the Dataweb, controlled resources are never addressed directly. They are always addressed through the link contract that establishes the data sharing relationship between the publisher and any subscriber. (This is sometimes called the “rights path”.)
Let’s illustrate this in the context of a business card sharing relationship. Say Alice and Bob want to begin sharing XDI business cards, and both of them have XRIs for their home pages at an XDI service provider. From a Dataweb perspective an XDI business card is simply an XDI document containing instances of contact data.^14 And a dynamic address book is simply a Dataweb site (or a branch of a site) devoted to sharing and linking XDI business cards.
Alice and Bob can each use a Dataweb editor^15 to create an XDI business card containing the contact data they would like to share. This is published to their respective Dataweb sites as shown in Figure 3.
Figure 3: Two Dataweb sites containing electronic business cards as XDI documents.
Alice must next choose a “template” link contract for sharing business cards. Typically this will be similar to a real-world contract template—a standard form with different customization options.^16 For example, it may let Alice set a default permission to permit contacts to forward her XDI business card directly to others (“introduction permission”), vs. needing Alice’s permission first. In any case, when Alice is finished customizing this template, she publishes it to her Dataweb site as shown in Figure 4.
Figure 4: Alice adds a link contract for sharing her business card.
To share this business card with Bob, Alice sends him the XRI for the link contract. This is where XDI service comes into play. When Bob clicks this link, Alice’s XDI service provider asks Bob for the XRI of his own XDI home page. After authenticating Bob with his XDI service provider, Alice’s XDI service provider sends him Alice’s link contract. Providing Bob agrees, Bob’s XDI service provider returns a signed version of the contract^17 and keeps a copy for Bob. Finally Alice’s service provider returns a copy of Alice’s business card to be cached by Bob’s site, as shown in Figure 5.
Figure 5: Both sites have a copy of the signed contract and Bob’s site has a cached copy of Alice’s business card.
Providing Alice has a persistent XRI, Alice and Bob have just created a lifetime link—one that won’t break no matter how many times Alice moves, changes jobs, or even changes XDI service providers. And if Alice’s contract includes data synchronization permission, updates to Alice’s contact data will automatically flow across to Bob’s site (via an XDI update message sent from Alice’s XDI service provider to Bob’s XDI service provider).
Bob can share his XDI business card with Alice the same way. This mirrors the exchange of XDI documents shown in Figure 5, and sets up a second “pipe” between their two Dataweb sites to keep Bob’s business card synchronized with Alice’s cache.
The advantage of this model for business card sharing is that, like the Web, it is the same for all Dataweb relationships—person-to-person, person-to-business, business-to-business. The types of data and the terms of the link contract may vary, however for most common types of data sharing transactions (like business cards), the link contract is likely to be very simple and standardized.
This model extends within a user or organization’s internal Dataweb as well. For instance, rather than look up Alice’s phone number online at his XDI service provider, where Bob really needs this data is directly on his laptop and cell phone. If these devices included an XDI dynamic address books linked to Bob’s XDI service provider, any updates to Alice’s business card would automatically flow right down to his local devices. In essence, they become local caches of a selected portion of Bob’s online Dataweb site.
(^12) The OASIS XDI TC will also consider include protocol-level support for basic transactional integrity.
(^13) XRIs are backwards-compatible with most HTTP URIs.
(^14) Most likely these datatypes will be identified with general XRIs assigned to standard contact datatypes such as those developed by the OASIS CIQ TC. See also the discussion of general XRIs and XDI dictionaries below.
(^15) This may be an online HTML application provided by an XDI service provider, or a new feature provided by a client-side contact manager such as Microsoft Outlook or Palm Address Book.
(^16) XDI personal link contracts are expected to be very simple, reflecting person-to-person trust relationships.
An appointment is just another group of shared data, so from a Dataweb standpoint every appointment is simply a new XDI document that needs to be shared among all attendees. Assuming this is controlled data, however, this first requires that attendees have a contract covering this type of data. Such a contract may include options such as, “Can this contact automatically schedule an appointment on my calendar? Can they move an appointment? Can they see an appointment that they have not created?”
Many XDI business card sharing contracts are also likely to include calendaring sharing. Let’s say this is the case with Alice’s contract with Bob, and now Bob wants to schedule a meeting with Alice. Bob could create a new XDI appointment and “invite” Alice by linking it to her contract, as shown in Figure 6.
Bob’s XDI service provider then sends the XDI appointment document to Alice’s XDI service provider. Assuming Alice handles appointment requests locally, Alice’s service provider would deliver the message to her preferred device (such as her laptop or cell phone), which would notify her as she desires (such as using an HTML email or SMS message). As with most calendar sharing systems, Alice can now accept, decline, or modify the request. If she accepts it, the result would look like Figure 7 (except that this appointment would also be cached locally on her laptop or cell phone, not shown.)
Of course the real productivity payoff is realized when conflicts arise and either Bob or Alice needs to move the appointment. Assuming both have permission, either could modify it, and the other will receive the proposed change automatically. Negotiation over conflicts and proposing alternative times can also be automated to the extent that Bob and Alice’s respective XDI calendaring applications support this.
None of this is new functionality—these features are staples of workgroup calendaring systems. The breakthrough is reaching a platform- and domain-independent solution that can make Internet calendar sharing as widely available as Internet email and the Web.
(^17) This could be using an XML digital signature, or whatever other means of verification is acceptable to Alice.
The third distributed data sharing challenge was being able to do searches across private sites—data that is not available publicly, but that could be very valuable if searchable across a federated trust community.
Today’s Internet search engines compile their indexes using automated “spiders”, programs that crawl Web sites and follow the links to discover new content.^18 Dataweb search engines will work the same way, only spiders will also crawl link contracts. In other words, on the Dataweb, data is indexed only by permission, and this permission is provided to spiders the same way it is provided to any other party, using link contracts. In turn, Dataweb search engines will control access to these indexes by authenticating search requests with the governing community.
To illustrate, let’s say Alice and Bob are both members of a scientific association that offers the benefit of searching across portions of member’s private profile data (for example, their plans to do future research in a specific area.) Offering this feature today would require building a special search site to index the data, creating user accounts on this site for all participating members, and requiring members to login to this site to perform trusted searches.
The Dataweb solution requires only that all participating members share a common link contract. This governs not only what data is searchable under what terms, but also provides each member with permission to conduct searches across the linked data. No special sites, no separate accounts, no additional passwords. Furthermore the system can grow and evolve simply by making changes to this common contract, for example, by adding new types of data.
Whats more, trust communities can be now be federated by linking their contracts. So if Alice’s and Bob’s scientific association were to form an alliance with another scientific association, and the two communities wanted to offer trusted search across their combined membership, this could be accomplished simply by creating a new contract that links their respective member search contracts.^19 Now a trusted search request from a member of either association would automatically be authenticated against both search indexes.
(^18) Google also pioneered the use of link metadata to optimize the resulting indexes.
(^19) This contract could also establish the XRI synonym mapping if the two communities were using different XDI datatypes.
Although the XDI data model is rooted in Web architecture, and its WSDL definition can be bound to other transport protocols besides SOAP, XDI is ideal as a Web service because it adheres to the classic tenets of Web services architecture: domain-independent application-to-application XML messaging using XML schema definitions, WSDL service definitions, and SOAP envelopes.
Thus XDI/SOAP is fully compatible with all emerging Web services standards including WS-Security, WS-Federation, WS-Inspection, WS-Routing, and WS-Reliable Messaging. So where does XDI fit with other Web services?
In a world of domain-specific Web services, the role of XDI is as a utility service—a generalized Web service that can be employed by other Web services to handle common data sharing transactions. For example, say a heavy equipment manufacturer offers a suite of Web services for generating orders, accepting invoices, and monitoring inventory from its supply chain. This suite uses a set of XML schemas and WSDL service definitions customized for the manufacturer's product line and accounting systems.
If this manufacturer wanted to add a new supplier and its sales representatives to its supply chain, the manufacturer could offer another special Web service for accepting this supplier's account data into the manufacturer's CRM. Alternatively the CRM vendor could offer a pre-packaged Web service for doing this same task. But in either case the supplier would have to implement another Web service client for communicating this account provisioning data. If the supplier serves 25 manufacturers, this could mean implementing 25 different account-provisioning clients all for the same standard data.
This would become much simpler and less costly if all parties to this supply chain used a generalized data sharing service such as XDI. Then one set of XDI transactions could transfer, link, and permanently synchronize all the account data. XDI could also be used to "bootstrap" the other specialized Web services by transferring the XSD and WSDL files (encapsulated as XDI documents) necessary to configure the supplier's Web service clients. Now the manufacturer's and supplier's respective systems would be ready to begin automated data interchange at a fraction of the time and expense.
A standardized data interchange service not only simplifies the creation of a new relationship, it also automates many standard relationship maintenance tasks. For example, if the manufacturer and supplier described above used XDI to link their shared data, then changes in either of their configurations—prices, contracts, sales representatives, XSD files, WSDL files—could flow automatically from one's XDI servers to the other's using the mediation of XDI link contracts without any custom programming or specialized administration.
XDI is also a very efficient way of applying SAML^20 authentication and authorization assertions, because in XDI every policy decision point is identified by the XRI for the authoritative link contract. And shared access control policies described in a language like XACML^21 could be implemented within or across organizations—even throughout the manufacturer's entire supply chain—by using shared XRIs to the same XDI link contract.
Lastly, this is a context in which persistent XRIs—XRIs that will not change for the lifetime of a relationship—provide significant benefits. For example, suppose the supplier underwent a major reorganization of its sales force, or was bought by another vendor and changed its name. The use of persistent XRIs means all the XDI links and contracts between the supplier and manufacturer will remain intact even when the DNS names changed. Furthermore, XDI synchronization would allow changes to attributes such as titles, roles, and contact data to automatically flow between the XDI systems.
(^20) Security Assertion Markup Language. See OASIS Security Services Technical Committee, http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security
(^21) Extensible Access Control Markup Language. See OASIS XACML Technical Committee, http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml
The scenarios above raise the question of how XDI is customized for specific types of data interchange. For example, different XDI data sets are needed to provision the supplier's accounts for a heavy equipment manufacturer vs. an airplane manufacturer vs. a plastics manufacturer. How does each manufacturer request just the specific data needed by their CRM system from the supplier's XDI service?
The Dataweb answer is identical to the Web answer: forms. Just as a Web server can request customized data from a Web browser using an HTML form, an XDI client or server can request instances of specific XDI datatypes from another XDI service using an XDI form. The key difference between HTML and XDI forms is that the latter are XDI documents designed for fully automated machine processing. In other words, an XDI form uses machine-readable:
XDI forms can also be chained together to provide workflow and multi-party data sharing transactions. In short, they are the mechanism that enables XDI to serve as a generalized solution to sharing many different types of data under many different contract terms and trust models.
The foundation of the Semantic Web—the W3C's term for a Web of machine-readable and understandable resources as opposed to human-readable content—is RDF (Resource Description Framework). RDF is an abstract model and XML syntax for expressing metadata about any URI-identified resource, from a Web page to a file to a media stream. The goal of RDF is to provide a common format for machine-understandable metadata that can be processed by any RDF-aware application.
Just as XDI can integrate directly with other Web services because it can be a Web service itself, XDI can integrate directly with RDF because:
However, since both XDI and RDF represent graphs of relationships between resources, they can interoperate at an even deeper level.
(^22) Every XDI resource is XRI-addressable, and every XRI can be transformed into valid URI.
RDF represents all relationships using tuples—three part statements consisting of a subject, predicate, and object.^23 For example: a book (subject) has a rating (predicate) of "four stars" (object). The descriptive power of RDF derives from the fact that any value of any property of any resource can be described using this basic construct.
RDF statements can also be nested, i.e., one statement can describe another. For example, you can have an RDF statement describing who said that a book has a rating of four stars. But since RDF syntax is based on tuples, doing this actually requires four tuples (a tuple for the new statement, and three tuples describing the new statement's relationship to the subject, predicate, and object of the first statement.) Known as reification, this is one of the most complex topics in RDF.^24
Since distributed data sharing depends heavily on describing nested data relationships, the XDI meta-schema takes a slightly different approach. As described above, it models data from the "inside out", i.e., by starting with a Data element for containing atomic data values and then using three elements to model the three types of UML relationships in which a Data element can participate:
The result is a model for graphing data relationships that is optimized for generalized distributed data sharing. The key word is optimized. In theory, both RDF and XDI graphs can describe the relationships between any set of URI-identifiable resources. But each graph is optimized for different purposes. The distinction is similar to that between Cartesian and radian coordinates—either can locate any point on a plane, but certain types of shapes (e.g., squares vs. circles) are much easier to describe using one or the other.
In particular, the XDI graph is optimized for describing relationships between shared resources. This is the nature of distributed data sharing. Every time data is shared, a copy of a resource—a new sub-tree—is instantiated at a new location on the global XDI graph. Because this new sub-tree has an inherent relationship to the original sub-tree, it can be represented simply by using:
The result is both a simple, efficient XDI operation and clean, relatively compact XML.
A second way the XDI graph is optimized for linking is the use of XRIs to identify every resource and link element. Because of this, every node in the XDI graph is directly addressable using both persistent and reassignable XRIs. In addition every node that has a global context (i.e., a globally addressable ancestor) is globally addressable.
A third way the XDI graph is optimized for linking is link contracts, discussed above. Every link element that needs to control its active data interchange relationship with the target resource can cache a copy of its link contract, as shown in Figure 2 above. This means each XDI link can be not just self-describing, but self-governing—an ideal architecture for distributed data mediation.
(^23) From an object-oriented perspective, this is the same thing as an object, property, and property value. See http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/#basic
(^24) See http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/#higherorder
(^25) Note that for privacy and data protection purposes, the XRIs at any Link node may be only a subset of the XRI synonyms used at the target Resource node (or at other Link nodes) for this resource. This is a secondary mechanism by which data authorities can control the sharing of their data.
There is a fourth way in which the XDI graph is optimized for distributed data sharing. Since data describing the same resource is often already widely distributed (such as the same registration data representing the same user on multiple Web sites), a key challenge in establishing a distributed data sharing infrastructure is “linking it up.” This requires:
The latter two problems hinge on solving the first one—mapping equivalence. XDI offers four tools specifically to help with this problem:
With XDI dictionaries, Dataweb mapping software can help automate the process of assigning XRIs and XRI synonyms to local resources, in the process building equivalence maps for linking this data with other XDI authorities. With such tools it may be possible, despite the four-dimensional challenges of distributed data sharing, to establish a global Dataweb almost as quickly as the World Wide Web formed.
Besides the Web and XML, the roots of the Dataweb are in data addressing and linking technology originally developed by the XNS Public Trust Organization.^26 This work was contributed to the OASIS XRI TC in January 2003 to help develop the abstract, location-independent identifier scheme necessary to support Internet-wide persistent linking and synchronization of data.
With the approval of the XRI Generic Syntax and Resolution Specification 1.0 as a Committee Draft^27 on January 19, 2004, the foundation is now set for the OASIS XDI TC to develop the other specifications required for a global Dataweb. These deliverables include:
In addition the XDI TC plans to work closely with other OASIS TCs as well as other standards bodies and industry consortiums. Initially the XDI TC will be forming liaisons with:
We invite other industry alliances, standards bodies, companies, and individuals interested in XDI and Dataweb development to join the OASIS XDI TC or to contact us regarding developing a liaison.
(^26) http://www.xns.org
(^27) http://www.oasis-open.org/apps/org/workgroup/xri/download.php/5109/xri-syntax-resolution-1.0-cd.pdf
(^28) https://www.trustedcomputinggroup.org/
(^29) http://www.tmforum.org/
(^30) http://www.istpa.org/
The task of establishing an Internet-wide data sharing infrastructure might appear overwhelming. However ten years ago, the idea of a global Web that put billions of linked documents at our fingertips appeared equally unthinkable. What the Web proved was that a simple, generalized model for content sharing and linking could grow exponentially as each new link was created.
The Dataweb proposes the same model for distributed data sharing. As shown in Figure 8, it combines the best features of the Web's linking model, Web Service's structured XML messaging model, and the Semantic Web's resource description model into an architecture that has the potential do for interoperable trusted data sharing what the Web did for open content sharing.
Web (HTML/HTTP) Web Services (XML/SOAP)
Figure 8: The Dataweb bridges the best features of the Web, Web Services, and the Semantic Web.
Moreover, XDI does not displace any of the existing or emerging XML vocabularies designed to support specific applications or Web services infrastructure. Rather, it augments them by providing a common Web service for sharing, linking, and synchronizing other XML documents encoded in any XML language or schema. XDI service is designed to layer over enterprise-level data sharing solutions and standards the same way the Web layered over enterprise-level content sharing solutions and standards.
The organizers of the OASIS XDI TC invite your participation in this work. For more information, please visit the OASIS XDI TC home page at http://www.oasis-open.org/committees/xdi.
<?xml version="1.0" encoding="ISO-8859-1" ?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://xdi.oasis-open.org"
xmlns:xdi="http://xdi.oasis-open.org"
elementFormDefault="qualified">
<element name="data">
<complexType mixed="true">
<sequence>
<any minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="xri">
<simpleType>
<restriction base="string">
<annotation>
<documentation>
This will contain an XML pattern element matching the XRI ABNF, so a standard XML schema validating parser will be able to validate that the XRI value is legal.
</documentation>
</annotation>
</restriction>
</simpleType>
</element>
<element name="resource">
<complexType>
<sequence>
<element ref="xdi:xri" minOccurs="1" maxOccurs="unbounded"/>
<element ref="xdi:data" minOccurs="0" maxOccurs="1"/>
<element ref="xdi:resource" minOccurs="0" maxOccurs="unbounded"/>
<element ref="xdi:link" minOccurs="0" maxOccurs="unbounded"/>
<any minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="link">
<complexType>
<sequence>
<element ref="xdi:xri" minOccurs="1" maxOccurs="unbounded"/>
<element ref="xdi:data" minOccurs="0" maxOccurs="1"/>
<element ref="xdi:resource" minOccurs="0" maxOccurs="unbounded"/>
<element ref="xdi:link" minOccurs="0" maxOccurs="unbounded"/>
<any minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
</schema>