RE: [xri] Proposed XRD schema

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

No reason. As I said, this was the exact approach I took with OAuth Discovery. Just wanted to make sure we are aware that there are many ways to skin an XRD...

EHL

> -----Original Message-----
> From: Brian Eaton [mailto:beaton@google.com]
> Sent: Friday, February 13, 2009 7:12 PM
> To: Eran Hammer-Lahav
> Cc: Dirk Balfanz; xri@lists.oasis-open.org
> Subject: Re: [xri] Proposed XRD schema
>
> Why is xsd:any *not* the answer to every single question raised in
> this thread, plus ones we haven't even thought of?
>
> On Fri, Feb 13, 2009 at 10:00 AM, Eran Hammer-Lahav
> <eran@hueniverse.com> wrote:
> > This came up for OAuth discovery as well (signature methods,
> parameter
> > methods, etc.). Overall the preference was to mint multiple types.
> However,
> > in this case there are infinite number of types because the
> attributes are
> > numeric, not one out of 3 or 4 options.
> >
> > I don't have anything against this proposal but I would suggest an
> > alternative for consideration that will avoid the need to extend the
> > namespace:
> >
> >
> <SubjectType>http://spec.openid.net/auth/2.0/ux/popup?height=500px;widt
> h=450px</SubjectType>
> >
> > Of course there are many ways to encode parameters into URIs (you can
> put
> > them in the path in a more RESTful way). But this way, the type is
> matched
> > up to the query ('?') and then the rest is considered parameters for
> those
> > who can understand the type.
> >
> > EHL
> >
> >
> > On 2/13/09 9:21 AM, "Dirk Balfanz" <balfanz@google.com> wrote:
> >
> > Hi there,
> >
> > so we were at the OpenID UX summit the other day and were discussing
> how an
> > OpenID OP can signal to an RP that it supports a "popup-style" login
> flow
> > (example: http://www.puffypoodles.com/popup).
> >
> > It seems clear that this would belong in the <SubjectType> element of
> the OP
> > endpoint's XRD, something like this:
> >
> > <SubjectType>https://spec.openid.net/auth/2.0/ux/popup</SubjectType>
> >
> > But what if the information to be conveyed to the RP is not just
> simply the
> > 1-bit information whether or not he extension was supported. In this
> case,
> > the OP might want to tell the RP also what size the RP should make
> the
> > popup. Where would that information go?
> >
> > One way to make this easier, and allow more structured attributes in
> > general, would be to say something like this instead:
> >
> > <SubjectType uri="https://spec.openid.net/auth/2.0/ux/popup"; />
> >
> > Now we could do this:
> >
> > <SubjectType uri="https://spec.openid.net/auth/2.0/ux/popup";>
> >   <height>500px</height>
> >   <width>450px</width>
> > </SubjectType>
> >
> > What do y'all think?
> >
> > Dirk.
> >
> > On Thu, Feb 5, 2009 at 4:26 PM, Eran Hammer-Lahav
> <eran@hueniverse.com>
> > wrote:
> >
> > Getting a draft out seems to be constantly slipping so below you will
> find
> > the proposed schema for XRD 1.0 with most elements explained. Please
> > comments, refine, redefine, etc. I will use this thread (and a wiki
> page if
> > someone supplements my laziness) and copy suggested text into the XRD
> 1.0
> > draft.
> >
> > EHL
> >
> > ---
> >
> > <XRD>
> >     <Expires> (unchanged)
> >     <Subject> (was CanonicalID)
> >     <Alias> (was EquivID)
> >     <SubectType required> (new)
> >     <Link priority> (was Service)
> >         <Rel> (new)
> >         <ResourceType> (was Type)
> >         <MediaType>
> >         <URI priority>
> >         <TemplateURI priority> (new)
> >         <LocalID priority>
> >
> > * <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 and 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 and must be an absolute URI.
> >
> > Provide aliases for the resource described by the XRD. Not allowed if
> no
> > <XRD:Subject> is defined.
> >
> > * <XRD:SubjectType required>
> >
> > 0 or more per <XRD> with type xs:anyURI.
> >
> > The <XRD:SubjectType> element declares an attribute associated with
> the
> > resource described by the XRD. The value of the <XRD:SubjectType>
> element is
> > a URI-formatted attribute-identifier. The meaning of the
> <XRD:SubjectType>
> > 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:SubjectType> 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:SubjectType>
> 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.
> >
> > * <XRD:Link priority>
> >
> > 0 or more per <XRD> and with no text, 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
> 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:TemplateURI> elements.
> >
> > * <XRD:Link:ResourceType>
> >
> > 0 or more per <XRD> with type xs:anyURI.
> >
> > The <XRD:Link:ResourceType> element provides hints as to the
> attributes of
> > the linked resource(s) identified using the <XRD:Link:URI> or
> > <XRD:Link:TemplateURI>.
> >
> > * <XRD:Link:MediaType>
> > * <XRD:Link:URI priority>
> > * <XRD:Link:TemplateURI priority>
> > * <XRD:Link:LocalID priority>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  Follow this link to all your TCs in OASIS at:
> > https://www.oasis-
> open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
> >
> >