|
FAQ .pdf format
January 20, 2004
This FAQ was created by the organizers of the OASIS XDI TC to provide background on its formation (http://www.oasis-open.org/committees/xdi/). Other introductory material on XDI includes:
What is XDI?
XDI (XRI Data Interchange) is a new generalized service being developed by the OASIS XDI TC for sharing, linking, and synchronizing data over the Internet (or any other data network) using a common XML representation, called an XDI document. Specifically, XDI consists of three parts:
The XDI Meta-Schema-a very simple XML schema that uses XRIs (Extensible Resource Identifiers) developed by the OASIS XRI TC to describe and link data that may be in many other native formats, including other XML schemas. XDI Service: a WSDL-defined protocol for exchanging data and metadata using XDI documents, together with bindings to different transport protocols (HTTP, SOAP, SMTP/MIME, etc.) The XDI Service Dictionary: a set of pre-defined XDI resources for describing other XDI resources and controlling XDI data interchange using XDI link contracts (see below).
Is XDI a Web service?
XDI over SOAP is a Web service. However XDI can also be bound to HTTP for use in "RESTful" architectures, as well as to other transport protocols like SMTP/MIME. So strictly speaking XDI is a generalized service based on XML document exchange that can be implemented as a Web service.
What are the primary problems XDI is intended to solve?
The general problem XDI is designed to address is interoperable, automated data interchange across distributed applications and trust domains. There are many specific examples of this problem:
- Exchange, linking, and lifetime synchronization of electronic business cards, public keys, and other common identity attributes across distributed directories (commonly known as dynamic address books).*
- Internet calendar sharing.*
- Trusted search (searches that need to cross multiple private websites).*
- Auto-configuration and intelligent data synchronization across multiple user devices (desktop, laptop, PDA, land phone, cell phone, etc.)
- Automated website registration, form-fill, and e-commerce transactions.
- Cross-domain security and privacy management.
* For detailed discussions of how XDI can be applied to these problems, see the XDI white paper at http://www.oasis-open.org/committees/download.php/5115/wd-xdi-intro-white-paper-2004-01-20.pdf.
What is the Dataweb?
The inspiration for XDI was the application of the architectural principles of the Web and XML to the problem of distributed data sharing. The result is called the Dataweb, as summarized in the table below:
|
Principle
|
World Wide Web
|
Dataweb
|
|
100% addressable resources
|
URIs
|
XRIs
|
|
Common representation and linking language
|
HTML
|
XDI Meta-Schema & XDI Service Dictionary
|
|
Common interchange protocol
|
HTTP
|
XDI/HTTP, XDI/SOAP
|
|
Logical organization and navigation of resources
|
Website
|
Dataweb site
|
In essence, the XDI meta-schema and protocol is to sharing and linking machine-readable data what HTML and HTTP are to sharing and linking human-readable content. In particular, Dataweb links are can define and control two-ways data sharing "pipes" between dataweb sites that can actively synchronize shared data when it changes, as illustrated below.
Why is existing URI syntax not sufficient for cross-domain data sharing?
While URIs in general, and HTTP URIs (commonly called URLs) in particular, have been spectacularly successful for building the Web, they are missing several features that are vital for cross-domain data sharing:
HTTP URIs do not provide absolute addressability of data instances down to any level of containment or nesting-they work only to the page or page fragment level. While XPath provides additional addressing features for XML documents, it operates only relative to XML document roots and is not integrated with HTTP URI syntax. HTTP URIs do not provide support for persistent addresses (the Dataweb equivalent of global foreign keys in databases). Other persistent URI schemes have been created, most notably the URN scheme, however they are not integrated with HTTP URI syntax and have not gained widespread adoption. HTTP URIs do not provide addressability of resources across contexts, i.e., the ability to share identifiers across multiple websites in order to identify the same logical resource in multiple domains or physical locations. This is extremely useful for cross-domain data sharing.
What features do XRIs have that URIs don't?
XRIs were developed by the OASIS XRI TC (http://www.oasis-open.org/committees/xri/) to build on the IETF URI specifications in the following ways:
XRIs are "location-independent" - the content of an XRI is decoupled from the network location of any data or services associated with the XRI. This means, among other things, that accessing a resource associated with an XRI isn't limited to a particular network location or protocol. (Most URI schemes in wide use today use identifiers that imply a close association to a network location or protocol.) XRIs can assert persistence of all or parts of an identifier. XRIs allow two types of separators (persistent and reassignable) between segments of an XRI, so the XRI can suggest that certain parts of the identifier are intended to be long-lived "primary keys" (a concept borrowed from database technology) and others are subject to change. Most URI schemes, on the other hand, are all-or-nothing. With URNs, for example, the entire identifier is persistent. With HTTP URIs, the entire identifier is potentially transient. The XRI scheme allows both characteristics to be combined in one federated identifier. XRIs provide the ability to "contain" other URIs or XRIs in the form of cross-references. Conceptually this is similar to using quote marks in English to talk about someone else's text. Cross references allow a well-defined URI or XRI to identify not only a concept or resource, but also to identify that concept or resource relative to another concept or resource. For example, a URI could identify a book, and an XRI could then identify a particular library's copies of the book by using that URI in a cross-reference appended to the library's XRI. So if " urn:isbn:0-131-10362-8" represents The C Programming Language by Kernighan and Ritchie, and "xri:@SeattlePublicLibrary" represents the Seattle Public Library, then "xri:@SeattlePublicLibrary/(urn:isbn:0-131-10362-8) " represents The C Programming Language in the context of the Seattle Public Library. XRIs also support self-references, a special form of cross-reference that indicates that an XRI is not intended to be resolved on the network but is intended solely as a unique identifier. For example, "xri:(@SeattlePublicLibrary/(urn:isbn:0-131-10362-8))" is a self-reference because it is entirely enclosed by parentheses, and as such represents the identifier itself. XRIs allow unlimited delegation of namespaces. While many URI schemes rely on DNS delegation, XRIs also have the ability to use abstract (non-DNS) names or identifiers that can contain a wider set of characters and strings. The XRI specification includes several global context symbols for this purpose (e.g., the "@" in "xri:@example/foo" represents a standard global namespace for organizations). In addition, a cross-reference can also serve as a namespace root, thus creating a private or community-based identifier space whose management is entirely community defined (for example, "xri:(http://www.example.com)/foo"). XRIs are fully internationalized. XRI syntax builds on the W3C IRI (Internationalized Resource Identifier) specifications that adapt URIs to the Unicode character set.
For more information, see the XRI Generic Syntax and Resolution Specification 1.0 (http://www.oasis-open.org/committees/download.php/5109/xri-syntax-resolution-1.0-cd.pdf).
How do XDI documents differ from HTML documents?
First, XDI documents are XML documents, so they take advantage of the many features of XML architecture. However XDI documents are similar to HTML documents in that they are the common data representation format used by all XDI Dataweb sites. In other words, a key purpose of XDI is to provide a "schema-neutral" format for expressing shared data. This is what allows XDI data elements to be easily shared, linked, and synchronized across any number of Dataweb sites the same way HTML or XHTML Web pages can be easily shared and linked across any number of Web sites.
How do XDI documents differ from conventional XML documents?
While XDI documents are valid XML documents, the key difference is that they use a very simple XML schema (the proposed XDI meta-schema) expresses the metadata normally encoded as XML element tags and attribute names as XRIs. By using this approach:
Every data element at any level of the XDI "graph" of data (including versions) becomes addressable using XRI syntax. Resources can be addressed with multiple XRIs (called XRI synonyms), including both reassignable and persistent identifiers. XRIs used to identify datatypes, taxonomy classifications, or ontology nodes can be shared across any number of applications, domains, and XDI documents (like generic nouns in the English language). Resources can be grouped and linked in any number of combinations. Authority for every resource can be clearly expressed by its XRI path(s).
Does XDI require that I re-code all my XML documents?
Absolutely not. Like SOAP, XDI documents can be used as "envelopes" for other XML documents that use any schema or schema definition language. And like XML Digital Signatures, XDI documents can also be: a) completely detached from the XML document they describe, or b) nested as elements within XML documents that are extensible or explicitly support XDI elements.
How does XDI differ from HTTP?
XDI service will most likely resemble HTTP closely-it will define the same basic GET/PUT/DELETE/POST operations on XRI-addressable resources instead of URI-addressable resources, with XDI documents specified as the default content type.
However the OASIS XDI TC will also study the need for addition verbs to support transactional integrity.
How does XDI differ from SOAP?
XDI might be called "SOAP for data sharing". In other words, the same way SOAP provides a standard XML envelope for cross-domain messaging, XDI provides a standard XML envelope for cross-domain data interchange. Of course an XDI envelope can go inside a SOAP envelope, which is exactly what happens in the XDI/SOAP binding. With XDI/SOAP, XDI functions as a standard Web service, and is interoperable with all other Web services standards and infrastructure.
Is XDI only for enveloping other data?
No. Like XML digital signatures, XDI documents can also be contained within conventional XML documents (enveloped), or they can be used to describe resources from which they are completely independent (detached). Of course these uses of the XDI meta-schema do not involve XDI service, which operates only on XRI-addressable resources, just as HTTP operates only on URI-addressable resources.
What are XDI link contracts?
If XML is self-describing data, then XDI is self-describing data sharing controls-XML that not only describes the data, but also describe the terms under which that data is shared by the relevant data authorities. These controls are called XDI link contracts.
Technically, an XDI link contract is an XDI document that references other XDI documents in order to describes the terms under which they are shared between two or more XDI authorities. They are directly analogous to real-world legal contracts that control the exchange of information between parties, such as a non-disclosure agreement (NDA).
Because link contracts are themselves XDI documents, they can be exchanged, negotiated, shared, and linked just like any other XDI data. This is how XDI data sharing communities can quickly evolve standard data sharing agreements that simplify the development and management of trust relationships.
How will link contracts reflect the large spectrum of data sharing policies?
A XDI link contract can be a blend of: a) XDI-readable policies (such as opt-in or opt-out privacy choices), b) references to other XML-readable policies, such as XACML, and c) references to human-readable policies. To the extent that link contracts are simple and machine-readable, they can become largely transparent to many routine data sharing transactions. To the extent they represent a complex and individualized relationship, they will require human review and negotiation.
Will there be standardized link contracts?
Undoubtedly. Part of the goal of XDI data sharing is to simplify and automate routing data interchange tasks, so standardized link contracts reflecting best practices in cross-domain data sharing are likely to evolve as quickly as standardized credit cardholder agreements.
What is an XDI form?
Just as HTML/XHTML forms are used to request data from humans, XDI forms are used to request data and form link contracts between dataweb sites. Unlike HTML forms, which are almost always processed by humans, an XDI form is an XDI document that is processed as a request for data by the receiving Dataweb site. Since all datatypes requested in an XDI form are identified with XRIs, if matching data instances are present on the receiving site, an XDI form can be filled out automatically. A human need be involved only if data is missing, multiple matches are possible, or the link contract requires human authorization.
What is an XDI dictionary?
Like a real-world dictionary, an XDI dictionary is a Dataweb site that publishes a set of "words" (XRIs) and "definitions" (XDI documents) for the purpose of helping establish equivalence across a community of users and applications. The biggest difference is that XDI dictionaries are machine-readable and can also support XDI links to subscribing Dataweb sites that have an interest in new or updated vocabulary.
What is the XDI Service Dictionary?
The XDI Service Dictionary, which is developed and maintained by the OASIS XDI TC, plays a special role because its purpose is to define the global set of XDI resources used to describe and control XDI data sharing using XDI forms and link contracts. In this respect it might be analogous to a specialized legal dictionary.
Will there be other XDI dictionaries?
Yes. Like real-world dictionaries, XDI dictionaries can be published by any authority and can cover any fields of interest, from very general to very specialized. Generalized XDI dictionaries will focus on the shared concepts common to almost all vocabularies (in the English language this would be the equivalent of Merriam Webster's or the Oxford English Dictionary). Such generalized dictionaries can address a longstanding problem in XML - how to establish XML elements that can be broadly shared across many XML schemas (the machine-language equivalent of generic nouns.)
More specialized XDI dictionaries or "glossaries" can also be developed to support data sharing needs of any community, from a global federation to an industry association to a company to a workgroup.
How does XDI address the complex security issues involved with cross-domain data sharing?
XDI is not a magic bullet for Internet security infrastructure. However it does introduce several potential new building blocks for such infrastructure, including: 1) a common scheme for persistent identification of data and data authorities (XRIs), 2) a common XML representation format for data interchange (the XDI meta-schema), and 3) machine-readable link contracts that can include publish-subscribe synchronization of security attributes, such as public key certificates.
In addition, an XRI secure resolution protocol is under development by the OASIS XRI TC. Contributors to this effort believe that a broadly distributed public key infrastructure (PKI) may be an ideal Dataweb application. Certificate authorities and registration authorities could operate as Dataweb sites, and certificates could be shared, revoked, and updated using XDI link contracts.
In any case, when XDI is bound to SOAP, the resulting Web service can apply existing and emerging Web services security standards, including SAML and WS-Security, to the problems of cross-domain data sharing.
How does XDI address the complex privacy issues involved with cross-domain data sharing?
Cross-domain privacy is a complex, multi-dimensional problem. However on this score XDI does promise a key breakthrough: XDI link contracts can provide a standardized way to both: a) persistently identify data and data authorities using XRIs, and b) represent domain-independent data sharing and usage controls. This architecture is a direct outgrowth of the ISTPA Privacy Framework developed by the International Security, Trust, and Privacy Alliance (www.istpa.org), so it explicitly addresses the requirements for cross-jurisdictional data protection.
XDI link contracts can reference or describe privacy policies in different domains, and they can also provide an automated mechanism for negotiating, recording, and updating the permissions specified by these policies (e.g., opt-in or opt-out). For this reason XDI service and the XDI Service Dictionary may offer a new tool for cross-domain privacy management that can supplement W3C's P3P (Platform for Privacy Preferences Project) and IBM's EPAL (Enterprise Privacy Authorization Language). (Note that XDI link contracts can also incorporate or reference P3P and EPAL privacy statements).
How does XDI relate to XNS?
You might say that XDI is "XNS v2". Much of XDI architecture is based on concepts originally developed in XNS (Extensible Name Service) v1.0 and v1.1 from the XNS Public Trust Organization (XNSORG). XNSORG contributed the XNS v1.0 and v1.1 specifications to the OASIS XRI TC to help develop the XRI identifier scheme, and they will also be contributed to the XDI TC to help develop the XDI specifications.
How does XDI relate to RDF?
This is a hard question to answer in a FAQ. A summary answer is that the proposed XDI meta-schema and RDF use slightly different models for graphing data relationships. This might be compared to the difference between Cartesian and radian coordinate systems. Either can identify any set of points in a plane, but each is optimized for certain kinds of geometric shapes (e.g., line figures vs. circles).
Following this analogy, RDF is a very robust, application-independent solution for describing any property of any URI-addressable resource, while XDI is optimized for a specific application: describing data sharing and linking relationships between XRI-addressable resources in XML. For example, in XDI:
All nodes of XDI documents are directly addressable using XRIs. XDI nodes can have multiple XRI addresses, including both persistent and reassignable addresses (very useful for cross-domain data mapping). XDI nodes are nestable to any level, just like XML elements. All XDI nodes can be efficiently linked using XRIs. Any subset of XDI nodes can be copied to another location in the XDI graph without breaking any internal addresses or links.
Like Cartesian and radian coordinate systems, RDF and XDI descriptions are interoperable. XRIs are URI-compatible, so XDI documents can contain RDF descriptions and vice-versa. Thus both can be used to describe the same resources, and it should be possible to programmatically convert between the two types of descriptions when necessary.
When does the XDI TC intend to deliver its first specifications?
The first deliverables, including the XDI meta-schema and XDI WSDL service definition, are planned for the summer of 2004. Early implementations of the proposed XDI meta-schema and XDI/HTTP are already in progress among XDI TC members, and the TC's emphasis will be to publish drafts of proposed specifications early in order to encourage such implementation feedback.
Who can I contact for more information?
Feel free to contact the XDI TC organizers Drummond Reed, Cordance (drummond.reed@cordance.net) and Geoffrey Strongin, AMD (geoffrey.strongin@amd.com), or visit the XDI TC home page at http://www.oasis-open.org/committees/xdi/.
|
