RE: [xri] Res decision #2: XRID structure strawman

["Barnhill William" <barnhill_william@bah.com>]

+1 for SOAP-style, -1 for URI style

 

What I'd love to see though is a XRI descriptor infoset, detached from a particular schema, with MUST understand requirement for implementers to understand the mapping to default (SOAP or URI) schema, and MAY understand other schemas such as RDF or XDI or even XMPP (Does the capabilities section of the SOAP style remind anyone else of the capabilities JEP?). Problem then becomes how do clients tell which schema an authority supports. Solution would be some kind of feature negotiation, which IMHO would be a good thing for future extensibility.  Down side is some added overhead for feature negotiation, but if implemented correctly this overhead would be minimal.

 

I don't think this is fleshed out enough to even be a strawman, but if others think it's a good idea I can develop it into a proposal. I'd rather get the draft further down the pipeline than hold it up for this, but I'd also like to keep both feature negotiation and infoset bindnigs a possibility. Whether they're good ideas or not, they are probably a topic for the next rev.

---

From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Thu 11/3/2005 12:38 AM
To: xri@lists.oasis-open.org
Subject: [xri] Res decision #2: XRID structure strawman

Per our agenda below, this is a strawman proposal for decision #2 on the structure of XRIDs for Committee Draft 02. This is Issue #10 on the Resolution change management page (http://wiki.oasis-open.org/xri/Xri2Cd02/ResolutionChanges). More background is available at:

 

            http://wiki.oasis-open.org/xri/Xri2Cd02/ReSolution/I10XridRefactor

 

 

This message boils down the last several weeks worth of discussion into *two* strawman proposals, each illustrating a different potential approach to the structure of XRIDs.

 

The first strawman I'll call the "SOAP-style" approach because it defines an XRID as an extensible container of XML blocks, each block containing a particular set of metadata describing a resource. It then defines one block of XML elements in the XRID namespace explicitly for XRI resolution, and a second block in the XRID namespace for generic description of other capabilities of a resource. Other specifications would be free to define their own "blocks" of metadata elements in their own namespaces, similar to SOAP.

 

The second strawman I'll call the "URI-style" approach because, although it follows the same high-level architecture as the SOAP-style approach, and could be extended in the same way, it only defines one block of XML elements that use URIs as descriptors. It then defines the XRI resolution services (which are all based on concrete HTTP/S URIs) in terms of these same elements.

 

*** SOAP-STYLE STRAWMAN ****

 

Psuedo-XML:

 

<XRIDS version="$v/2.0">

            <XRID version="$v/2.0">

                        <Query>query-xri</Query>

                        <Expires>expiry-date-time</Expires>

                        <ProviderID>persistent ID for XRID provider</ProviderID>

                        <Synonym>synonymous XRI assigned by same ProviderID</Synonym>

                        <XSynonym>synonymous XRI assigned by different ProviderID</XSynonym>

                        <XRIResolution>

                                    <GenericAuthority version="version#" priority="10">

                                                <URI>http or https URI</URI>

                                    </GenericAuthority>

                                    <TrustedAuthority version="version#" priority="10">

                                                <URI>http or https URI</URI>

                                                <ProviderID>persistent ID for XRID provider</ProviderID>

                                                <dsig:keyinfo>key info</dsig:keyinfo>

                                    </TrustedAuthority>

                                    <Local version="version#" priority="10">

                                                <URI>http or https URI</URI>

                                    </Local>

                                    <Redirect>

                                                <URI>http or https URI</URI>

                                                <MediaType>application/xxxx</MediaType>

                                    </Redirect>

                        </XRIResolution>

                        <Capabilities>

                                    <Service>

                                                <Type version="version#">anyURI that defines service<Type>

                                                <MediaType>application/xxxx</MediaType>

                                                <URI>anyURI that provides endpoint for service</URI>

                                                <ProviderID>persistent ID for service provider</ProviderID>

                                                <dsig:keyinfo>key info</dsig:keyinfo>

                                    </Service>

                                    <Service>

                                                <Type version="version#">anyURI that defines service<Type>

                                                <URI>anyURI that provides endpoint for service</URI>

                                    </Service>

                                    <Service>

                                                <Type version="version#">anyURI that defines service<Type>

                                    </Service>

                        </Capabilities>

            </XRID>

</XRIDS>

 

Notes:

* All <Service> children are optional. A <Service> element that contains only a Type element describes a capability of the described resource that does not need a separate URI, i.e., there is some other way of interacting with or using this capability.

* The version attribute is used everywhere as a string that describes the version of the element/type that it describes.

* The extensibility model would be the same as CD01, i.e., each defined XML block may be extended internally, and additional XML blocks can be put inside the XRID container.

 

*** URI-STYLE STRAWMAN ****

 

Psuedo-XML:

 

<XRIDS version="$v/2.0">

            <XRID version="$v/2.0">

                        <Query>query-xri</Query>

                        <Expires>expiry-date-time</Expires>

                        <ProviderID>persistent ID for XRID provider</ProviderID>

                        <Synonym>synonymous XRI assigned by same ProviderID</Synonym>

                        <XSynonym>synonymous XRI assigned by different ProviderID</XSynonym>

                        <Service>

                                    <Type>xri://$resolution*authority*generic*($v%2F2.0)<Type>

                                    <URI priority="10">http://xri.generic.authority.tld/path</URI>

                                    <URI priority="15">http://xri2.generic.authority.tld/path</URI>

                        </Service>

                        <Service>

                                    <Type>xri://$resolution*authority*trusted*($v%2F2.0)<Type>

                                    <URI>http://xri.trusted.authority.tld/path</URI>

                                    <ProviderID>persistent ID for service provider</ProviderID>

                                    <dsig:keyinfo>key info</dsig:keyinfo>

                        </Service>

                        <Service>

                                    <Type>xri://$resolution*local*($v%2F2.0)<Type>

                                    <URI>http://xri.local.authority.tld/path</URI>

                        </Service>

                        <Service>

                                    <Type>xri://$resolution*uri*($v%2F2.0)<Type>

                                    <MediaType>application/xxxx</MediaType>

                                    <MediaType>application/yyyy</MediaType>

                                    <URI>anyURI</URI>

                        </Service>

                        <Service>

                                    <Type version="version#">anyURI that defines a service<Type>

                                    <MediaType>application/xxxx</MediaType>

                                    <URI>anyURI that provides endpoint for service</URI>

                                    <ProviderID>persistent ID for service provider</ProviderID>

                                    <dsig:keyinfo>key info</dsig:keyinfo>

                        </Service>

                        <Service>

                                    <Type version="version#">anyURI that defines a service<Type>

                                    <URI>anyURI that provides endpoint for service</URI>

                        </Service>

                        <Service>

                                    <Type version="version#">anyURI that defines a service<Type>

                        </Service>

            </XRID>

</XRIDS>

 

Notes:

* In this format, all capabilities of an resource are described in the same way (using <Service> elements and their child <Type> elements).

* Versioning of service types can either use the version attribute of <Type> or XRI versioning cross-reference syntax in the <Type> value (or define a different element).

* The extensibility model would be the same, i.e., any other child element of <XRID> could be defined in its own namespace, or any other child element of <Service>.

 

I believe both of these strawmen meet all the requirements we have been discussing; deciding on them appears to be more a matter of design preferences.

 

=Drummond  

 

---

From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Wednesday, November 02, 2005 11:42 AM
To: xri@lists.oasis-open.org
Subject: [xri] XRI Res CD02 proposed decision tree

 

I've talked with Gabe and there is a clear sense at this point that we need to move from the high-level conceptual definition of XRI resolution down into the concrete decisions we need to make to arrive at XRI Resolution 2.0 Committee Draft 02. As best we can tell, these decisions fall into four buckets:

 

1) Refactoring the Res CD01 spec (for readability and to remove most of the non-normative material).

 

2) Structure of an XRID.

 

3) Structure of an HXRI (HTTP XRI – the form of an XRI that can be resolved using an HTTP proxy resolver).

 

4) Rules/requirements for proxy resolution.

 

We would like to suggest that:

 

a) This week's two calls (Thurs. 9AM PT and Fri 8:30AM PT) focus on these four topics, with the goal of driving to consensus on each of the four as quickly as possible so that the editors can proceed into drafting ASAP.

 

b) TC members who care about these topics submit and discuss strawman proposals on each of the four via email prior to the the calls so that we're not starting discussion from scratch.

 

No response = agreement on this process, so you feel we should use a different process, speak up. Otherwise we'll make this our call agenda for Thursday/Friday and invite submissions/discussions of strawmen beginning immediately.

 

=Drummond