OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xri] Proposed XRD schema


How would xsd:any work?

I like the querystring parameter idea, but the library I'm using does string matching as well. We could specifies a "starts-with" match of the url before the querystring though. Most if not all languages have that...

Nika
-----Original Message-----
From: Brian Eaton <beaton@google.com>

Date: Fri, 13 Feb 2009 19:11:31 
To: Eran Hammer-Lahav<eran@hueniverse.com>
Cc: Dirk Balfanz<balfanz@google.com>; xri@lists.oasis-open.org<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;width=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
>
>
>
>

---------------------------------------------------------------------
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 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]