RE: [xri] <Type>

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

And yes, there will be no restrictions on multiple properties with the same type.

EHL

> -----Original Message-----
> From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
> Sent: Monday, November 09, 2009 9:17 AM
> To: George Fletcher; xri@lists.oasis-open.org
> Cc: Drummond Reed
> Subject: RE: [xri] <Type>
> 
> 
> 
> > -----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
> > >
> 
> ---------------------------------------------------------------------
> 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