Re: [xri] <Type>

[George Fletcher <george.fletcher@corp.aol.com>]

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
>