[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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: 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. 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]