Alternative ways to extend resource attributes

[Eran Hammer-Lahav <eran@hueniverse.com>]

Title: Alternative ways to extend resource attributes

Use case:

A resource supports a protocol extension that requires some configuration parameters, for example, a Pop-up mechanism. To indicate support for this extension, the XRD contains a special type URI:

<XRD>
    <SubjectType>http://example.com/extension/popup</SubjectType>
</XRD>

Use of the popup requires 2 parameters, height and width. The question is, how these two parameters can be encoded into the XRD.

Solutions:

1. Query parameters

<XRD>
    <SubjectType>http://example.com/extension/popup?height=400&width=300</SubjectType>
</XRD>

2. Custom XRD-Level elements

<XRD>
    <SubjectType>http://example.com/extension/popup</SubjectType>
    <x:Popup>
        <x:Width>300</x:Width>
        <x:Height>400</x:Height>
    </x:Popup>
</XRD>

3. Self-Link with ‘self’ Rel

<XRD>
    <SubjectType>http://example.com/extension/popup</SubjectType>
    <Link>
        <Rel>self</Rel>
        <ResourceType>http://example.com/extension/popup</ResourceType>
        <x:Width>300</x:Width>
        <x:Height>400</x:Height>
    </Link>
</XRD>

4. Self-Link with no Rel

<XRD>
    <SubjectType>http://example.com/extension/popup</SubjectType>
    <Link>
        <ResourceType>http://example.com/extension/popup</ResourceType>
        <x:Width>300</x:Width>
        <x:Height>400</x:Height>
    </Link>
</XRD>

5. SubjectType child elements with URI as attribute

<XRD>
    <SubjectType identifier=”http://example.com/extension/popup”>
        <x:Width>300</x:Width>
        <x:Height>400</x:Height>
    </SubjectType>
</XRD>

6. SubjectType child elements with URI as child

<XRD>
    <SubjectType>
         <Identifier>http://example.com/extension/popup</Identifier>
        <x:Width>300</x:Width>
        <x:Height>400</x:Height>
    </SubjectType>
</XRD>

7. Parameters as SubjectType attributes

<XRD>
    <SubjectType x:height=”400” x:width=”300”>http://example.com/extension/popup</SubjectType>
</XRD>

Comments:

#5 and #6 require schema changes for the XRD
#1, #2, and #7 are all allowed under the current XRDS extension architecture
#3 and #4 are allowed but should be explained by the spec as they are not intuitive to most people


EHL