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>


I'm just catching up on this thread and I agree with all comments made so far. I especially agree that it will dramatically lessen the need for extension elements using other XML namespaces.

My only suggestion regarding <Property> child elements of a <Link> is that the spec should be very clear that these are descriptions of the properties of the LINK to the related resource, not properties of the related resource itself.

That distinction is easily lost unless we reinforce it.

=Drummond


On Mon, Nov 9, 2009 at 9:20 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
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]