[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] <Type>
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]