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


Yes I can imagine an OpenID selector aka "active client" use <Property> that way..

Markus

On Mon, Nov 9, 2009 at 12:09 PM, George Fletcher <george.fletcher@corp.aol.com> wrote:
I agree this model make XRD very extensible very easily. I'm assuming that multiple Property elements are valid... meaning that the same <Property type="key"> pairs can be repeated.

 <Property type="http://example.com/version">1.1</Property>
 <Property type="http://example.com/version">2.0</Property>

I can see the "active client community" leveraging this change to describe the required "policy" for a particular IdP endpoint.

 <Link rel="http://specs.openid.net/auth/2.0/return_to" href=""http://consumer.example.com/return">
  <Property type="http://openid.net/rp/ax/1.0">http://axschema.org/contact/email</Property>
  <Property type="http://openid.net/rp/ax/1.0">http://axschema.org/namePerson/friendly</Property>
 </Link>

Of course the OpenID community (or the active client community) would describe how all this would work. I like the extensibility but I'm a little worried that by making this so flexible we'll end up with documents that are very hard to read, write or process.

Thanks,
George


Eran Hammer-Lahav wrote:

This of course raises the question of supporting the <Property> element as a child of <Link>. Seems to make sense, especially considering the OpenID delegation use case (not sure it is still valid but a good example), where such an element will remove the need to define another XML namespace. It is also in line with the HTTP Link header which explicitly allows extensions in the form of key/value pairs.

This model makes XRD truly extensible without the need to extend the schema in every use case I am aware of. And in term of spec change, once we define the element, it is just another line to add it under Link.

Thoughts?

EHL

> -----Original Message-----
> From: drummond.reed@gmail.com [mailto:drummond.reed@gmail.com] On
> Behalf Of Drummond Reed
> Sent: Friday, November 06, 2009 5:37 PM
> To: Eran Hammer-Lahav
> Cc: xri@lists.oasis-open.org
> Subject: Re: [xri] <Type>
>
> Yup, IMHO it makes sense to go from <Type> to <Property
> type="uri-goes-here">value-if-not-empty<Property>.
>
> =Drummond
>
> On Friday, November 6, 2009, Eran Hammer-Lahav <eran@hueniverse.com>
> wrote:
> > I have been thinking about James' feedback regarding the need for
> key/value pairs to describe resources, and I have been convinced that
> it makes more sense than the current Boolean approach taken with
> <Type>.
> >
> > Right now, we can describe a resource using only a list of "tags".
> While protocols can customize these to include configuration:
> >
> > <Type>http://example.com/version/1.1</Type>
> > <Type>http://example.com/version/2.0</Type>
> >
> > Or
> >
> > <Type>http://example.com/popup/size/300,400</Type>
> >
> > This approach has been rejected by most members a few months back as
> a bad extensibility model.
> >
> > To make XRD useful we should either drop <Type> and leave it up to
> individual extensions to define a container that is useful for them to
> describe the resource, or replace <Type> with a key/value element such
> as:
> >
> > <Property key="http://example.com/version">1.1</Property>
> >
> > Ignore the element syntax, use of value or attributes or child
> elements. The key will be a URI (just like <Type>) and the value a
> string. A key without value is the same as a <Type> declaration.
> >
> > Thoughts?
> >
> > EHL
> >
> >
> > ---------------------------------------------------------------------
> > 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


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