RE: [xri] <Type>

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

> -----Original Message-----
> From: George Fletcher [mailto:george.fletcher@corp.aol.com]
> Sent: Monday, November 09, 2009 9:09 AM
> To: xri@lists.oasis-open.org
> Cc: Eran Hammer-Lahav; Drummond Reed
> Subject: Re: [xri] <Type>
> 
> 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</P
> roperty>
>     <Property
> type="http://openid.net/rp/ax/1.0";>http://axschema.org/namePerson/frien
> dly</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.

This would be even more true if we force every rel type to define its own child elements...

EHL

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