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


I was about to raise the same question. The extensibility model of XRD has
always been to allow extension attributes and elements throughout; Gabe very
carefully architected it for that.

I would much prefer sticking with that and not requiring any special
matching rules for URIs contained in elements or attributes. That way you
leave those namespaces completely under the control of the URI authors, who
often have their own uses for query parameters, paths, fragments, etc.

=Drummond 

> -----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;width=4
> 50px</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]