About

This page contains the strawman for the XRD 1.0 schema. It is being used to coordinate XRI TC discussions on the schema prior to publication of the first Working Draft.

The following started from this email to the list from Eran Hammer-Lahav. We are updating it as discussions evolve so we have one place to reference the "current best thinking" and any open issues until the XRD 1.0 spec is mature.

Schema Overview

<XRD>
    <Expires>                       ;unchanged
    <Subject>                       ;was CanonicalID in XRDS
    <Alias>                         ;was EquivID in XRDS
    <Type required>                 ;new (different semantics than it had in XRDS)
    <Link priority>                 ;was Service in XRDS
        <Rel>                       ;new (similar to Type in XRDS)
        <MediaType>                 ;unchanged
        <URI priority>              ;unchanged
        <URITemplate priority>      ;new
        <Subject>                   ;was ProviderID

Element and Attribute Definitions

<XRD>

The document root element.

<XRD:Expires>

0 or 1 per <XRD> element with type xs:dateTime.

The date and time without fractional seconds in UTC "Z" time zone, after which the XRD descriptor MUST NOT be used. If the XRD was obtained via HTTP, and the HTTP headers specified an expiry time per section 13.2 of [RFC2616], the XRD descriptor MUST NOT be used after the earlier of the two values passed.

<XRD:Subject>

0 or 1 per <XRD> with type xs:anyURI. Must be an absolute URI.

The canonical identifier. The subject of the XRD which is described by the other elements.

<XRD:Alias>

0 or more per <XRD> with type xs:anyURI. Must be an absolute URI.

Provide aliases for the resource described by the XRD.

<XRD:Type required>

0 or more per <XRD> with type xs:anyURI.

The <XRD:Type> element declares an attribute associated with the resource described by the XRD. The value of the <XRD:Type> element is a URI-formatted attribute-identifier. The meaning of the <XRD:Type> value is application-specific, and is used by the XRD provider to describe the resource to consuming applications familiar with the attribute-identifier. The attribute-identifier is used in a similar manner to XML namespace-identifiers.

The <XRD:Type> element supports the 'required' attribute with allowed values 'true' and 'false'. If not present, the attribute default value is 'false'. If the 'required' attribute is omitted or explicitly set to 'false', a consuming application SHOULD ignore any <XRD:Type> with values it does not recognize, and interact with the resource based on the values it does recognize.

However, if the 'required' attribute is set to 'true', a consuming application MUST NOT interact with the resource if it does not recognize the element value. The 'required' attribute is used to indicate to a consuming application that some predefined knowledge is required in order to interact with the resource, without which undefined or potentially harmful side-effects can occur. The 'required' attribute SHOULD NOT be used unless such harmful side-effects are likely.

0 or more per <XRD>. Permits only child elements.

The <XRD:Link> element declares a relationship between the resource described by the XRD and other resources. The <XRD:Link> element uses the typed-link framework defined by [Link-Header] and carries a similar semantic meaning as the HTML <LINK> element [HTML-Link], the ATOM <Link> element [ATOM], and the HTTP Link header [Link-Header]. For example, the Link header:

    Link: <http://example.com/author>; rel="author"; type="text/plain"

Maps to the following XRD fragment:

    <Link>
        <URI>http://example.com/author</URI>
        <Rel>author</Rel>
        <MediaType>text/plain</MediaType>
    </Link>

It is important to note that unlike the HTML <LINK> element [HTML-Link], the ATOM <Link> element [ATOM], and the HTTP Link header [Link-Header], the link relationships described by the <XRD:Link> element are between the resource described by the XRD and the linked resources, and not between the resource described by the XRD and the XRD resource itself.

<XRD:Link:Rel>

0 or more per <XRD> with type xs:anyURI.

The <XRD:Link:Rel> element defines the relationship between the resource described by the XRD and the resources listed using the <XRD:Link:URI> and <XRD:Link:URITemplate> elements.

[Add more about the semantics of this element and how it plays the same role as the rel element in Link Headers.]

<XRD:Link:MediaType>

TODO

<XRD:Link:URI priority>

TODO

<XRD:Link:URITemplate priority>

TODO

<XRD:Link:TargetSubject>

TODO (see open issues below)

<XRD:Link:SourceAlias priority>

TODO (see open issues below)

Open Issues

<XRD:Link:TargetSubject> (was <XRD:Service:ProviderID>)

For synonym trust verification, we need the ability to have a child element of <XRD:Link> that references the canonical URI for the target of the link. (In XRDS, this was the <XRD:Service:ProviderID> element.) In other words, if the link target resource has its own XRD, then this element would have the same value as the <XRD:Subject> element of that XRD.

Note that this can be different than the value of a <XRD:Link:URI> or <XRD:Link:URITemplate> element, because those elements MAY assert a URI for the link target resource that is not canonical (i.e., a URI that would be the value of an <XRD:Alias> element in an XRD describing the link target resource).

The cardinality of this element is the same as XRD:Subject, i.e., 0 or 1.

The name <XRD:Link:TargetSubject> is proposed for this element because, as described above, if the link target resource has an XRD, this would be the value of its <XRD:Subject> element.

Conclusion: Subject instead of TargetSubject. Subject of Original XRD need to match the subject of linked XRD.

<XRD:Link:SourceAlias> (was <XRD:Link:LocalID>)

The identifier(s) for the subject of the XRD (the values of the <XRD:Subject> and <XRD:Alias> elements) may NOT be the same identifier(s) used to identify that same resource in the context of the link target resource. Thus an link child element is needed for an XRD to assert one or more identifiers for the XRD subject in the next of the link target. An example is OpenID "identifier delegation": mapping the identifier asserted by the OpenID user to the alias used by the OpenID Provider (OP), which may be different.

XRI and XDI architectures also need this capability of being able to map different context-specific identifiers for the same logical resource across different contexts.

The proposal is to express this mapping semantics more precisely by renaming this element to <XRD:Link:SourceAlias>. The term "Source" is used to make it clear that the identifier is for the resource at the source of the link (not the target). The term "Alias" is used to make it clear that this is an alternate identifer than the Subject (otherwise the consuming application can just use the <XRD:Subject> identifier by default).

Conclusion: Removed as it is rel specific.

XrdOne/XrdSchema (last edited 2009-08-12 18:07:17 by localhost)